Re-applies 4 custom Readwise features on top of upstream v13.16.0:

1. setTintColor command - controls WebView selection/tint color via RGBA
   doubles. Fixed Fabric signature to match codegen protocol (4 doubles
   instead of UIColor), preventing SIGABRT on New Architecture.

2. scrollsToTop prop - controls scroll-to-top on status bar tap.

3. dragInteractionEnabled prop - controls drag interactions on the webview.

4. forceLightScrollIndicators is NOT re-added — upstream v13.14.0+ has
   indicatorStyle prop which supersedes it with more flexibility.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

WKWebView pages loaded with about:blank origin (via loadHTMLString:baseURL:)
cannot access file:// URLs. This custom scheme handler serves files from the
app bundle (fonts, etc.) via rw-asset:///filename URLs, bypassing the
file:// security restriction.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Readwise/v13.16.0

Commit 010b9de added scrollsToTop, dragInteractionEnabled, and
setTintColor to the codegen spec (RNCWebViewNativeComponent.ts) but
only implemented them on iOS. Codegen generates a single Java interface
for all platforms, so Android fails to compile without these stubs.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add Android no-op stubs for iOS-only codegen props

- Remove lib/ from .gitignore and commit pre-built output
- Rename prepare script so it doesn't auto-run during pnpm git installs
- Disable packageManager field to prevent pnpm from invoking yarn

This makes the git-hosted fork behave like an npm-published package:
consumers get pre-built output without needing yarn to build.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

When iOS triggers a Universal Link handoff mid-flow inside a WebView, the
user is yanked into the linked third-party app and the embedded flow
breaks. This shows up most commonly in embedded auth: e.g. a Goodreads
sign-in WebView whose post-Amazon-SSO redirect lands on a UL-eligible
URL like /ap-handler/sign-in?IDP=lwa, sending the user into the
installed Goodreads app.

iOS does not expose a way to predict UL handoff at the navigation
delegate — UL is decided in WebKit's process before
decidePolicyForNavigationAction fires. The only nav type iOS reliably
does NOT consider for UL handoff is host-app-initiated
[webView loadRequest:].

This adds a preventUniversalLinks prop (NSArray<NSString *>) for iOS:
when set, top-frame navigations whose host matches an entry are
canceled and re-issued via [webView loadRequest:]. Match is
domain-suffix with a dot boundary, so passing 'goodreads.com' covers
'goodreads.com', 'www.goodreads.com', and any subdomain — but not
'evilgoodreads.com'.

The prop takes a host list rather than a boolean because reissuing
every top-frame nav unconditionally breaks anything that's not a plain
GET — POST form bodies are stripped by NSURLRequest in the navigation
action, and reissuing single-use OAuth codes (Amazon callbacks etc.)
double-consumes them. Only hosts that actually have AASA registered
for this app's bundle ID are at risk of UL handoff, so the app
declares them.

An associated-object flag on the WKWebView breaks the cancel/reissue
loop: the reissued nav re-enters decidePolicyForNavigationAction with
the flag set, the impl clears it and falls through to the normal
handler.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
(cherry picked from commit 7fbf264)

Add preventUniversalLinks prop to sandbox hosts from UL handoff