build: resume a grant sign-in when its relay poll dies

[jvsena42]

Stacked on #296 (base feat/restore-grant-auth). GitHub's stacked PRs aren't enabled for this repo, so this is a plain stack: merge #296 first, then retarget this to main.

Picks up jvsena42/pubky-core-ffi-fork#7. When a grant sign-in's relay long-poll dies, the FFI restores the flow onto the same relay channel instead of failing. The approval waits in the relay inbox for ~5 minutes, so the user never approves twice.

Why

On the emulator the "HTTP transport error … httprelay.pubky.app" sign-in failure was DNS, not a cut long-poll. The full cause chain ends dns error: failed to lookup address information: No address associated with hostname: an ~18 s system-resolver timeout, then instant failures from its cache. That outlasts the time it takes to approve. Bitkit's approval was measured landing 2.7 s after Loopky had given up, in an inbox nobody read.

What's in it

• The native libraries only: Android (4 ABIs), iOS xcframework, macOS + Linux desktop. The generated Kotlin/Swift bindings are byte-identical, so no API changes.
• The two KDocs (RingAuthFlowHandle, loopky login) and the Architecture §13 paragraph that said a failed poll has no in-place retry now describe the resume and its bounds.
• A journeys/RESULTS.md entry for the run below.

The resume's rules, from fork#7: it rejoins only when the failing URL is the relay's own (a homeserver-side failure comes after the approval was ACKed); it rides out ≤ 90 s of outage, backing off 1→8 s; and it stops at 170 s, just under OnboardingViewModel's 3-minute approval timeout, which can't interrupt the blocking call.

Verified on the emulator, with Bitkit as the signer

Wi-Fi + data cut for 20 s mid-wait	Poll dies on the DNS error; 9 restores back off 1→8 s
Network back, approve in Bitkit	Approval delivered; the resolver keeps failing for another ~43 s
A restore collects it after 33 s in the inbox	session saved → SUCCESS
Revalidate · deck list	✅ · ✅
Self-tag write	❌ 403 Write to this path is not allowed (see below)

That run used a 60 s outage allowance; fork#7 ships 90 s, because 55 of the 60 were used. :shared:jvmTest (real desktop libpubkycore), :cli:test, assembleDebug and the iOS simulator build pass.

Not Loopky, but worth knowing

• The self-tag 403 is that identity's account, not the grant. "Write to this path is not allowed" is the homeserver's per-user allowed_write_paths quota check. A grant with the same client_id and caps, for another staging account, writes the same /pub/pubky.app/tags/<id> path fine. Raised on feat: support Pubky signup synonymdev/bitkit-android#1224, together with two Bitkit quirks: it drops a deep link that arrives during its cold start, and it doesn't return via x-success.
• Pre-existing, not addressed here: if an approval lands after OnboardingViewModel's 3-minute timeout on a healthy link, the VM reports a timeout and discards the session the FFI just collected. withTimeoutOrNull can't interrupt the blocking call (Architecture §13.10).

🤖 Generated with Claude Code

https://claude.ai/code/session_01QC3jMBnPioeidFuV1JjEQ6