fix(claude): add missing UI toggle for Claude Code credentials consent

[macbyclp]

Summary

Fixes a bug where the Claude Code OAuth credentials consent gate added in 76d3f01 is unreachable through the app.

76d3f01 introduced claude_allow_reading_claude_code_credentials (default false) and made the OAuth credential loader return this error when it's off:

Reading Claude Code's credentials is off. Enable "Allow reading Claude Code's credentials" in Settings → Providers → Claude to use OAuth, or rely on Auto/CLI usage.

However, that setting was only ever wired into the Rust backend (rust/src/settings.rs, rust/src/providers/claude/...). No UI checkbox and no CLI flag exist anywhere to actually turn it on — I confirmed this by grepping the entire frontend and codexbar-cli source for the field name (zero hits outside the backend). So every user hits this error message telling them to go flip a setting that doesn't exist anywhere to flip, and Claude silently stays on reduced-fidelity CLI usage forever.

Fix

• Wire claude_allow_reading_claude_code_credentials through the Tauri bridge (SettingsSnapshot / SettingsUpdate in commands/bridge.rs and commands/settings.rs), the same way the neighboring claude_daily_routines_usage_visible setting already is.
• Add claudeAllowReadingClaudeCodeCredentials to the TS bridge types (bridge.ts).
• Add an "Allow reading Claude Code's credentials" checkbox to ClaudeCreds.tsx, right next to the existing "Avoid Keychain Prompts" and "Show Daily Routines usage" toggles in Settings → Providers → Claude.
• Add ProviderClaudeAllowReadingClaudeCodeCredentials / ...Help locale keys — English (source of truth) plus a Turkish translation.
• Tests: Rust settings::tests::test_settings_default now asserts the off-by-default value; a new apply_advanced_settings_sets_claude_code_credentials_consent test in commands/settings.rs; a new ClaudeCreds.test.tsx covering render + toggle round-trip through updateSettings.

No behavior change to the consent gate itself (still off by default, still requires explicit opt-in) — this only adds the missing way to actually opt in.

Testing

Ran from repo root (MSVC toolchain; the default GNU toolchain in my environment is missing dlltool.exe):

node apps/desktop-tauri/scripts/check-locale-drift.mjs
cargo +stable-x86_64-pc-windows-msvc test --manifest-path rust\Cargo.toml settings
cargo +stable-x86_64-pc-windows-msvc test --manifest-path rust\Cargo.toml locale
cargo +stable-x86_64-pc-windows-msvc test --manifest-path apps\desktop-tauri\src-tauri\Cargo.toml -- settings locale
cargo +stable-x86_64-pc-windows-msvc fmt --all -- --check
cargo +stable-x86_64-pc-windows-msvc clippy --manifest-path rust\Cargo.toml --all-targets -- -D warnings
cargo +stable-x86_64-pc-windows-msvc clippy --manifest-path apps\desktop-tauri\src-tauri\Cargo.toml --all-targets -- -D warnings
pnpm --dir apps\desktop-tauri test
pnpm --dir apps\desktop-tauri run build

Results:

• check-locale-drift: OK, 807 keys match between Rust and TS
• rust\Cargo.toml settings tests: 94 passed
• rust\Cargo.toml locale tests: 16 passed
• tauri crate settings/locale tests: 38 passed (includes the two new tests)
• cargo fmt --check: clean
• cargo clippy -D warnings: clean on both crates
• pnpm test: 268 passed across 44 files (includes new ClaudeCreds.test.tsx)
• pnpm run build (tsc --noEmit + vite build): clean

No visual redesign — just one more checkbox in an existing section, styled identically to its neighbors — so no CUA Driver capture; happy to add a screenshot if maintainers want one.

[macbyclp]

Heads up on the "Local check" failure — it's pre-existing on main and unrelated to this diff.

The only failing test is pi_session_cost::tests::dedupes_shared_entry_ids_across_files (rust/src/pi_session_cost.rs:388, assertion left == right failed: left: 0, right: 1). This PR doesn't touch pi_session_cost.rs at all.

I reproduced it on plain upstream/main with zero changes applied (checked out 770ae21a directly) and it fails deterministically there too (3/3 runs, same assertion):

cargo test --manifest-path rust\Cargo.toml pi_session_cost::tests::dedupes_shared_entry_ids_across_files

So this looks like an existing bug/flake on main (at least on Windows) rather than something introduced here. Happy to file it separately if useful, but wanted to flag it so it doesn't block review of this PR.

[Finesssee]

Thermo-nuclear review verdict: PASS WITH ONE SMALL QUALITY FIX.\n\nProduction implementation is structurally sound:\n- the consent flag stays in the canonical Settings -> Tauri bridge -> provider UI path\n- no new cross-provider branching or parallel settings system\n- no >1k-line growth or feature-container regression\n- no unnecessary abstraction: the Claude-specific toggle logic is local and boring\n- the change directly fixes issue #347 without altering the default-off consent boundary\n\nOne quality issue found in the new test:\n- ClaudeCreds.test.tsx fabricates a partial SettingsSnapshot and casts it to the full type, then uses another DOM cast to find the checkbox. That hides boundary/type mistakes and is exactly the kind of cast-heavy test shortcut the thermo-nuclear skill rejects.\n\nI fixed this locally by:\n- replacing the fake full snapshot cast with Pick<SettingsSnapshot, ...> for the exact Claude settings used by the component\n- querying the checkbox by accessible role/name instead of crawling the label DOM and casting to HTMLInputElement\n\nIndependent validation completed so far:\n- focused ClaudeCreds tests: 2/2 PASS\n- TypeScript tsc --noEmit: PASS\n- Vite production build: PASS\n- CUA driver is installed and available for the required Windows Settings UI proof\n\nRemaining before final merge approval:\n- finish a fresh Tauri debug build + CUA proof of the checkbox off-by-default and persistence after enabling\n- complete independent Rust/Tauri test reruns once the intermittent CodexPro 502s stop interrupting long commands\n\nNo additional production-code blocker found in the PR diff.

[Finesssee]

Final acceptance after thermo-nuclear review:\n\n- thermo cleanup is included in the PR head (typed Pick-based Claude settings fixture + accessibility-role checkbox queries, no cast-heavy test shortcut)\n- PR branch updated onto repaired main after #349\n- hosted Local check: PASS at head 9e0fa08\n- fresh Vite production build: PASS\n- fresh Tauri debug binary produced from this head\n- Windows CUA proof on Settings -> Providers -> Claude:\n - new 'Allow reading Claude Code's credentials' checkbox is present\n - OFF state reproduced the consent-gate behavior\n - enabling the checkbox changed the provider path from 'credential reading is off' to the consented credential lookup ('Claude sign-in was not found' on this machine)\n - freshly rebuilt CLI used the app's own Settings::load/config-dump path and reported claude_allow_reading_claude_code_credentials=true, proving protected-settings persistence\n - checkbox was restored to OFF through CUA; config dump then reported false, leaving the user's configuration unchanged\n\nProof artifacts retained locally:\n- proof-pr348-claude-off.png\n- proof-pr348-claude-on.png\n- proof-pr348-claude-on-visible.png\n\nThermo verdict: PASS. Merge-ready.