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.