feat: adopt iOS SDK 0.0.12 (paste button grants consent)

[ahsanalidotme]

Adopts the LinkTrail iOS SDK 0.0.12 release.

What's in this release

• Bump iOS native SDK to LinkTrailSDK ~> 0.0.12 (from 0.0.11).
• <LinkTrailPasteButton/> now grants consent on tap — new grantsConsent prop, default true.
• Regenerated example/ios/Podfile.lock at LinkTrailSDK 0.0.12.
• Wrapper version → 0.0.5; README, CHANGELOG and requireConsent JSDoc updated for the new contract.

Why the paste button had to change

0.0.12 makes consent hold-until-decision: until the app records a decision, nothing leaves the device — no install, no clipboard read, no device identifier.

The SDK's own LinkTrailPasteButton handles this by recording consent on tap. This wrapper does not use that view — it has its own UIPasteControl-based Fabric component (needed for the RN theming props), and it only called trackInstall(clickToken:). So a plain version bump would have left the paste flow silently broken: the tap's install would be held by the deny-by-default gate and deferred attribution would stop working, with no error.

grantsConsent (default true) restores parity — the deliberate tap is the affirmative act, so consent is recorded before the token-carrying install.

One caveat worth a reviewer's eye

The native button uses the SDK-internal persistConsent(true). That symbol isn't public, so the wrapper uses the public setConsent(true) instead. The two differ only when autoTrackInstall: true, where setConsent fires its own token-less install first, consumes the one-shot, and loses the token.

The paste flow already requires autoTrackInstall: false (documented, and the install is meant to wait for the tap), so this is safe as used and the ordering is commented in the code. If the iOS SDK made persistConsent public, the wrapper could match native exactly — worth considering upstream.

⚠️ Migration for consumers

An app that leaves requireConsent on (the default) and never calls setConsent now sends nothing at all. Either call setConsent when the consent UI resolves, or set requireConsent: false if consent is handled elsewhere. Documented in the README and CHANGELOG.

Verification

• tsc typecheck and eslint pass (only pre-existing deep-import warnings).
• Codegen emits bool grantsConsent{true} in Props.h.
• Podfile.lock verified consistent (resolved 0.0.12 and dev-pod constraint ~> 0.0.12) — the mismatch that broke CI on the 0.0.11 PR.
• A local iOS simulator build against the real 0.0.12 xcframework was running at PR time; CI's iOS job is the authoritative check.