feat: guest login credentials, stale-key handling, and sign-in link refresh

[leggetter]

Companion PR

Coordinate with hookdeck/core #5233 — that PR owns API, Dashboard CliAuth, Console analytics, and L3 journeys. Merge core first, then this PR.

---

Why we're doing this

Same motivations as core #5233:

1. Product / UX — default hookdeck login after listen claims and upgrades the same guest sandbox (signupGuest), so the developer keeps their Console work instead of landing on a disconnected account. The CLI sends guest attestation on POST /cli-auth — guest_user_id + guest_api_key so the server can prove the caller is that guest — which enables that in-place upgrade. Keeping one PostHog distinct_id through guest → signup is the analytics consequence, not the primary user benefit.
2. Product — long listen sessions must not show an expired Console sign-in link; refresh the 1h /signin/guest?token=… URL automatically.

Measurement note: only Journey A (default claim) gets a clean, linked conversion. Journeys B and C leave the guest sandbox behind; those conversions are not linked to the guest person (see core #5233).

---

CLI behaviour (no flags — follows CLI profile)

Behaviour is driven by what's stored in the profile after listen / logout. There is no auth_intent flag and no TTY prompt.

Path	When	POST /cli-auth body	Browser opens	Outcome
A — Claim sandbox (default)	Guest profile present (guest_url set)	guest_user_id + guest_api_key (guest attestation)	Signup → CliAuth	Same user upgraded; Console sandbox kept → Console
B — Existing Platform account	After hookdeck logout (guest fields cleared)	device_name only	Signin → CliAuth team picker	CLI on existing Platform org; guest sandbox left on the original guest account, not carried over
C — Accidental new signup	Same as B, user clicks Sign up on signin page	(none — signin ticket)	Signup + abandon banner → onboarding	New Platform org; guest sandbox left on the original guest account, not carried over; CLI Guest Sandbox Abandoned on core

hookdeck listen
hookdeck login              # A: claim guest sandbox (default)

hookdeck logout             # required for B — clears guest creds so login uses sign-in, not signup
hookdeck login              # B: sign in to existing Platform account
# If you then click "Sign up" in the browser → C

Path B note: use this when you already have a Hookdeck Platform (Dashboard) account and want the CLI on that org. Without hookdeck logout first, the CLI still has guest credentials and the default sends you to signup (path A), not sign-in.

Claim path details (A)

• Valid guest API key does not skip the browser — CLI still calls StartLogin so the user can complete signup / signupGuest.
• Stale guest API key (401 on validate): preserve credentials for the POST, clear the stored key, continue browser login with guest attestation (guest_user_id + guest_api_key so the server can prove the caller is that guest).

Existing Platform account (B)

• hookdeck logout clears guest_user_id, guest_api_key, and guest_url from the profile.
• Next hookdeck login sends device name only → Dashboard signin URL.

Listen guest URL (separate from hookdeck login)

The TUI link to open Console in a browser (/signin/guest?token=…). This is not the hookdeck login claim flow.

• RefreshGuestSigninLink on listen start and ~50m TUI tick → POST /cli/guest/signin-link (core endpoint).
• Mints a fresh token for the same URL shape; destination after auth is unchanged (Console).

MCP hookdeck_login follows the same guest vs logged-out rules.

---

Code changes

• pkg/login/client_login.go — guest credentials on POST; stale-key handling; logout clears guest fields
• pkg/login/guest_link.go — refresh helper + listen integration
• pkg/login/guest_link_test.go — refresh success, API error fallback, missing profile no-op
• test/acceptance/guest_login_acceptance_test.go — guest POST body vs after logout

---

Test plan

• go test ./...
• go test -tags=guest ./test/acceptance/... — guest profile POST body vs after logout
• go test ./test/acceptance/... — stale validate 401 → browser flow (login_auth_acceptance_test.go)
• pkg/login/guest_link_test.go
• Pair with core staging / L3 Playwright (core #5233 test plan)

Depends on

core #5233: origin_guest_user_id, guest attestation (guest_user_id + guest_api_key on POST /cli-auth so the server can prove the caller is that guest), POST /cli/guest/signin-link, CliAuth guest-claim completion.