Embedded Vibe auth: keyring credential (ai.mistral.vibe) lifecycle + refresh for the hosted process — no browser cookies #1712

Part of the Vibe-embedding epic (ACP-hosted vibe-acp).

Rule (Drew, standing, 2026-11-05)

No provider may depend on a non-renewing browser cookie. Anything browser-born must have auto-renew built in (auto-renewing cookie or long-lived token with its own refresh). The embedded Vibe path must ride the keyring/OAuth credential with its own refresh — never the Mistral console session.

Current facts

• The credential lives in the OS keyring as service ai.mistral.vibe (username MISTRAL_API_KEY), landed by the one-time vibe --setup sign-in (2026-11-04). The vibe-direct shim already resolves it via the binary's own order (config → env → ~/.vibe/.env → keyring).
• ACP initialize advertises one auth method: browser-auth ("Sign in through Mistral AI Studio"). With the keyring credential present, the 2026-11-05 spike needed no authenticate call — session/new and the turn just worked.
• Mistral docs: "Vibe stores the key in your OS keyring, or in ~/.vibe/.env when no keyring is available, and reuses it across sessions." (https://docs.mistral.ai/vibe/code/use-vibe-in-other-ides)

Scope

• The hosted vibe-acp process resolves the same keyring credential (same user/session context — keyring access needs the user session bus; the service/supervision design must guarantee it, as tonight's runs did via the laptop user session).
• Detect credential expiry/revocation from ACP errors and surface it as a named, actionable state (re-run of the one-time sign-in), never as a silent provider failure or a fallback to console cookies.
• Prove rotation: replace the keyring entry (the RustDesk-drift lesson — stored credentials drift) and show the hosted process picks up the new value without code or config changes.

Acceptance

• Embedded turns succeed with only the keyring credential present (no browser session, no console cookies anywhere in the path — verified by running with the browser closed/logged out of the console).
• A deliberately invalidated keyring entry produces the named re-auth state in the UI/logs, and restoring a valid entry recovers without restart of anything else.