Pubky SDK 0.11 (Ring sign-in unchanged)

[BitcoinErrorLog]

Ring sign-in on @synonymdev/pubky 0.11 (PR 1 of the Bitkit grant-auth wave, #48 / #49)

Moves the Shop to @synonymdev/pubky 0.11.0, the version Bitkit's Paykit rc55 and upstream pubky-app use, and keeps Pubky Ring on the cookie flow with the same single approval. Nothing changes for Bitkit yet: PR 2 adds the Bitkit grant sign-in on top of this.

Design: /Volumes/t7/vibes-dev/.evidence/bitkit-signin-grant-48/REPORT.md rev 2, rows R1.1–R1.9 (design review round 2: SHIP_DESIGN).

Changes

• @synonymdev/pubky 0.8.0 → 0.11.0, pinned exactly, with the @bitcoinerrorlog/pubky-shop override set to 0.11.0. The lockfile has one copy.
• Renames: startAuthFlow → startCookieAuthFlow, signer.signin() → signinCookie(), signer.signup() → signupCookie(), including the probe scripts.
• Cookie hydration uses Session.restore(base64(body), client) on the one-approval /session POST, on its GET recovery, and on cookie reload. On 0.11, Pubky.restoreSession parses exportLocalSecret() tokens, so hydration through it fails after the user approved.
• Staging direct signup hydrates with Session.restore. If all three attempts fail after the invite is spent, it recovers through signinCookie before throwing a retryable error. This fixes the P1 recorded on the parked sync/upstream-2026-09-20 @ 288f417e.
• PkarrError from the SDK maps to a retryable network error (upstream chore(deps): bump @synonymdev/pubky to 0.11.0 pubky/pubky-app#2529).
• paykit-wasm (vendor/paykit-wasm, used by messaging) is untouched.

Contract rows → tests

Row	Test
R1.1 Ring QR shape	homeserver.ring-url.contract.test.ts › ring qr matches captured 0.8.0 host and params. Real SDK, fixture captured from 0.8.0 in src/test/fixtures/auth/ring-signin-url.sdk-0.8.0.json.
R1.2 One approval, dual POST	auth.single-approval-seams.test.ts › runs homeserver-then-marketplace exactly once, with identical body bytes on both POSTs (now also asserts Session.restore, never Pubky.restoreSession)
R1.3 /session hydration	homeserver.test.ts › signInWithFullGrantAuthToken suite (POST, standard base64 alphabet, GET recovery, restore failure), all on Session.restore
R1.4 Cookie reload	homeserver.test.ts › reload restores cookie session via Session.restore. Gate sdk-call-sites.gate.test.ts › no Pubky.restoreSession call site in src
R1.5 Signup after a spent invite	homeserver.test.ts: the staging signup hydration asserts Session.restore; plus recovers via signinCookie when every restore attempt fails after the invite is spent and throws a retryable error only when both restore and signinCookie fail
R1.6 Renames	existing homeserver tests with renamed mocks. Gate no removed 0.8 cookie API names on the pubky SDK
R1.7 PkarrError	homeserver.test.ts › pkarr error maps to retryable network error
R1.8 Step-up by another pubky	auth.single-approval-seams.test.ts › step-up approved by a different identity mints no marketplace bearer and signs the session out
R1.9 Dependencies, paykit-wasm untouched	gate one @synonymdev/pubky 0.11.0 in lockfile. git diff origin/release/shop-v0.6.8 -- src/core/services/paykit/paykit-messaging.ts vendor/paykit-wasm is empty.

Both new gates were run once against a deliberate bad input and failed: the fixture host changed to signin_grant, and a pubkySdk.restoreSession( call site added. The log is in pr1/calibration.log.

Proof

• Real Chromium on staging (local next dev against the staging homeserver, relay and staging-api.pubky.app; staging seller test seat 7oboeqnf…): 10/10 on head 7724b848.
  • Ring sign-in QR keeps the 0.8.0 shape (signin, caps,relay,secret).
  • One approval, then one homeserver POST /session (200) and one marketplace POST /v1/auth/sessions (201).
  • Reload keeps the cookie session.
  • Ring signup (hs, st, the Shop capabilities) takes one approval and hydrates the new identity.
  • Files: log pr1/chromium-pr1.log, screenshots pr1/chromium/, script pr1/chromium-pr1.mjs.
• Gate: prettier/eslint/typecheck/6,379 related unit tests/718 marketplace VRT pass; non-marketplace VRT project crashes before any spec on the unchanged release head 55a084c too (pre-existing, handed to the gate owner); CI runs the full VRT. Logs: pr1/prepush.log, pr1/vrt-other-rerun.log, pr1/vrt-other-release-head-55a084c8.log.

Evidence root: /Volumes/t7/vibes-dev/.evidence/bitkit-signin-grant-48/.

Notes for review

• Auth change: Terra review and Kimi audit on this frozen head.
• Rebased onto the release head after Sign-in: show the QR without waiting for the pubky.app bridge #98 (skip the session-bridge probe on /sign-in); that behaviour is unchanged.
• Not proven in Chromium: browser-generated-key staging signup (onboarding "Create keys in browser"). In the dev harness, Continue made no /signup request before any SDK call, which points at the ceremony's local-state guard, not the SDK. R1.5 is covered by the unit tests above.