bug: pubky sign-in link can still time out on cold start while paykit holds the shared-state lock #1541

Refs:

• fix: keep pubky sign-in links working on a cold start #1514
• bug: pubky sign-in from a link fails on the first try when bitkit cold-starts #1513

What happened?

On a cold start from a pubkyauth://signin_grant link, the Pubky session restore can be deferred with shared_state_busy past the 60 s sign-in wait, and the link then fails with "Failed to initialize Pubky deeplink". The startup identity republish and the public Paykit endpoint refresh hold the SDK's shared-state lock while the restore retries. @jvsena42 saw it in 2 of 8 cold starts on staging (details): the restore succeeded 6 s after the wait expired; a later PIN run took 65 s.

Expected behavior

A sign-in link that cold-starts Bitkit opens the Authorize sheet within the wait. Startup Paykit work (identity republish, endpoint refresh) yields to the session restore while a sign-in link is waiting, or the lock contention is resolved in paykit-rs.

Steps to Reproduce

1. Create a profile on staging.
2. adb shell am force-stop to.bitkit.dev, then at once adb shell am start -d '<fresh pubkyauth://signin_grant link>'.
3. Repeat a few times and watch PubkyRepo.kt:531 "Deferred session restoration … shared_state_busy" lines.
4. Observe the restore finishing after the 60 s wait and the link failing.

Additional context

Two related deferral behaviours from the same runs:

• A bitcoin: URI arriving while the PIN screen holds a deferred sign-in link replaces it, and the sign-in link is dropped.
• A URI arriving while the Authorize sheet is open replaces the sheet with Send.