fix(auth): pin the Ring deeplink back to cookie, which is all v1.19 can parse (#321)

[jvsena42]

Sign-in with Pubky Ring has been broken since #296. The cause is not in that PR's logic — it is
that no Ring release can parse the grant deeplink it mints — but the fix is here, because Ring
cannot ship on our schedule.

Pins startAuthFlow/awaitAuthApproval and the signup intent host back to the cookie variants.
Everything else #296 landed stays.

What was actually wrong

Ring v1.19's APK carries lib/arm64-v8a/libpubkycore.so at md5
af6af1809d6e6767b82b51c3a00c2584, 9,718,912 bytes — byte-identical to the pre-0.10 binary
that react-native-pubky#39 replaced (9718912 -> 10651088). No signin_grant string, no
parse_deep_link symbol; the parser is the 0.9.1 one, which accepts the intent hosts "",
signin and signup and returns Invalid auth URL intent 'signin_grant' for anything else.

The npm package is fine — @synonymdev/react-native-pubky@0.14.0 ships md5 89709ec8…,
10,651,088 bytes, three signin_grant hits — so v1.19 was built against a stale cache. Filed as
pubky/pubky-ring#375. Nothing is pending upstream: v1.19..origin/main is one unrelated commit
and no Ring PR or issue touches deeplink parsing.

The control that had been recorded wrong

#296 and journeys/RESULTS.md both say a freshly minted cookie URL is rejected by v1.19 too,
and conclude v1.19 breaks sign-in either way. It does not reproduce. Back to back on
emulator-5554, same minute, both URLs minted by our own FFI in a scratch :shared:jvmTest and
sent with adb shell am start -a android.intent.action.VIEW -d '<url>' to.pubky.ring:

Input to Ring v1.19	Result
pubkyauth://signin?caps=…&relay=…&secret=…	✅ "Select Pubky — authorize this service"
pubkyauth://signin_grant?…&cid=loopky.app&cpk=…	❌ [InputRouter] Unknown input format

That row is why two sessions went looking for a Ring parser bug rather than a stale binary, so it
is corrected in RESULTS.md rather than quietly overwritten.

Verified on a device

With this build installed, Loopky mints pubkyauth://signin?… (logcat) and Ring raises the
approval prompt — the step that was impossible on grant.

The round trip still does not complete on the emulator, and not because of this change. The
relay long-poll fails inside the app process with the resolution failure already recorded on
2026-09-10: attempt 1 dies after a ~20s lookup timeout, attempts 2 and 3 instantly, and pubky's
poller gives up after three. Other Loopky traffic succeeds the same second and ping httprelay.pubky.app from the device shell answers, so it is this process's resolver. Survived a
reboot, an IPv4-only network and a resolver bounce.

One real cost, stated rather than buried: the resume that rides such an outage out (fork#7 /
#298) is await_grant_auth_approval only. pubky 0.10's cookie flow exposes no save_local/
restore to rebuild it from, so await_cookie_auth_approval dies on the first outage. Building a
cookie resume against a pin meant to be short-lived is not worth it — but it means a flaky network
now breaks Ring sign-in where it recovered before, and it is the second reason to lift the pin
promptly.

Undoing it

#321 lists the five places to revert, and PubkyClient.startAuthFlow's KDoc says revert rather
than rebuild. Gate: a Ring APK whose libpubkycore.so hashes to the npm package's.

./gradlew detektAll :shared:jvmTest :cli:test lintSwift green; :androidApp:assembleDebug built
and driven on emulator-5554.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WkPJoKxLJnigyfL6eKfPFW

[jvsena42]

Round trip confirmed — sign-in completes end to end on the pinned build (maintainer's device, 2026-09-13): mint → Ring prompt → approval → session. Journey 01 updated to PASS.

The emulator-5554 failure described above stands as an environment blocker (that process's resolver losing httprelay.pubky.app), not a result of the pin — though the missing cookie-flow resume is what makes it terminal there, which is still the second reason to lift #321 promptly.