feat(tui): in-TUI Spotify auth trigger from Settings tab

[vxcozy]

Summary

• New Verb::StartAuth + Event::AuthStarted|Completed|Failed round-trip lets users kick off the Spotify OAuth PKCE flow from inside the TUI instead of dropping to a second shell for clitunes auth.
• Keybind: press a on the Settings tab. While pending the tab says "Opening browser… waiting for Spotify"; on success the status badge flips to "Logged in" automatically via a follow-up Verb::ReadConfig; on failure the reason is shown inline until the next retry.
• 5-minute timeout on the daemon-side flow so walked-away users don't end up with a zombie pending state.

Why

PR #58 surfaced auth state on the Settings tab but still asked users to drop to another terminal to actually authenticate. Single-pane users (tmux-less, SSH with one pane, iTerm tabs-only) hit that friction every first-run; the taped-over hint "Run clitunes auth in another terminal to sign in" felt like a TODO we'd shipped.

The daemon already owned the credential-cache write path via load_or_authenticate. The gap was a verb that triggered it and an event topic that streamed progress. This PR closes that gap without touching the existing clitunes auth subcommand — both entry points coexist.

Phase 1 findings (auth-flow daemon-drivability)

• librespot-oauth 0.8's get_access_token is cleanly daemon-drivable when the redirect URI carries a port (ours: http://127.0.0.1:8898/login). It binds its own HTTP listener and never reads stdin in that path.
• The browser is opened via librespot's bundled open::that_in_background; SSH / no-browser environments still get a functional auth URL printed (today that print is lost to the daemon's /dev/null stdout — surfacing the URL to the TUI requires a librespot-oauth public API change and is out of scope for this PR).
• ensure_consent in auth.rs reads from stdin, so the daemon can't call load_or_authenticate directly. This PR adds a sibling authenticate_from_daemon that skips the stdin prompt (the a keypress counts as consent at the UI layer) and reuses run_oauth_flow + save_cached unchanged.

Wire shape

Verb (no payload, idempotent):

Verb::StartAuth  // "start_auth" on the wire

Events (topic "auth"; clients subscribe alongside config):

Event::AuthStarted { url: Option<String> }  // url reserved; None today
Event::AuthCompleted
Event::AuthFailed   { reason: String }

Daemon-side, dispatch_verbs owns an Arc<AtomicBool> guard so overlapping StartAuth verbs coalesce; subsequent verbs ack ok: true but emit no duplicate events. The flow itself runs under tokio::task::spawn_blocking wrapped in tokio::time::timeout(5min); all three terminal states (ok / err / elapsed) map to a single AuthCompleted or AuthFailed { reason } event.

Tests

• New state.rs tests: a starts auth when logged out, is ignored while pending or already logged in, and retries cleanly after a failure (the stale error banner clears).
• New paint.rs tests: pending-state message replaces the sign-in hint; failure reason renders in a Last attempt failed: banner.
• New verbs.rs / events.rs roundtrip tests for the four new wire types.
• Existing settings-tab tests updated for the new "Press `a` to sign in" copy and the a auth footer hint.

Test plan

• cargo fmt --check clean
• cargo clippy --workspace --all-targets -- -D warnings clean
• cargo test --workspace --all-features — all suites green; default-features build + tests green too
• Manual smoke: open picker, 4 → Settings, a → browser opens + pending copy shown, complete auth → status flips to "Logged in" on its own
• Manual smoke: a with no network → ~5min later, AuthFailed { reason: "timeout" } surfaces inline

Scope discipline

• No config-write path (device name / Connect toggle remain editor-only) — that's a future slice.
• No changes to the existing clitunes auth subcommand.
• Visualiser reactivity files untouched (CLI-91 is in a parallel worktree).

Closes clitunes-y53 / CLI-92

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.