feat: add TUI login profile picker

[shiny-code-bot]

Why

Codex Lab is moving toward dogfooding with multiple auth accounts. The CLI auth-profile work gave us named credential stores, but the TUI still lacked an ergonomic way to choose which saved login should back the current session.

This adds the first /login TUI surface so a user can inspect saved profiles and start a fresh session using one of them. Because auth is process-scoped in the embedded app-server, the TUI does an embedded-server restart for profile switches instead of pretending that a per-thread config change is enough. Shared daemon and remote app-server sessions now get an explicit restart-with---auth-profile message.

What Changed

• Added /login as a slash command with a searchable profile picker.
• Added direct selection via /login default and /login <profile>.
• Added AppEvent::SwitchAuthProfile and a TUI switch path that:
  • resolves the selected profile to an auth_home,
  • starts a replacement embedded app-server with that auth storage,
  • cleans up the old thread before swapping clients,
  • starts a fresh session with the selected login.
• Updated app-server account login writes to use config.auth_home rather than config.codex_home.
• Added focused tests for picker rendering, profile selection event emission, and auth-home storage resolution.

Verification

• cargo test -p codex-tui login_slash_command
• cargo test -p codex-app-server account_login_storage_uses_auth_home
• cargo check -p codex-tui
• cargo fmt --manifest-path codex-rs/Cargo.toml --all -- --check
• git diff --check

Notes

In-TUI creation of new login profiles is intentionally left as a follow-up. The picker points users at codex-lab login --profile <name> until the app-server login endpoints are profile-aware enough to support a full in-TUI add-account flow safely.