fix(codex-oauth): surface secret-tool failure reason on credential save (#1338)

[0xghost42]

Closes #1338.

Summary

The Codex OAuth flow on Ubuntu / GNOME (and any Linux desktop without a working Secret Service) ends in the generic dialog:

Codex OAuth succeeded, but credentials could not be saved securely.

That message is the catch-all fallback in `useCodexOAuthFlow` for when `saveCodexCredentials` returns `{success: false}` without a `warning`. Tracing it back: `saveCodexCredentials` opts out of plaintext fallback (`allowPlainTextFallback: false`), so on Linux it hits `linuxSecretStorage.update`, and that path swallowed every `secret-tool` failure mode into a bare `{success: false}` with no diagnostic. Two of the most common Linux failure modes:

1. The `secret-tool` CLI is not installed (`libsecret-tools` missing on Debian/Ubuntu, `libsecret` missing on Fedora).
2. The Secret Service / gnome-keyring is not running, the default keyring is locked, or there is no D-Bus session (very common over SSH without an active desktop session).

The result is identical from the user side: OAuth succeeded, generic save-failure message, no path forward.

Fix

`src/utils/secureStorage/linuxSecretStorage.ts` `update()` now mirrors the existing pattern in `windowsCredentialStorage`:

• Capture the `secret-tool` stderr from the `execaSync` result and surface it verbatim (prefixed with `secret-tool:`) when present.
• Detect `ENOENT` (missing binary) both by `error.code` and the error message, and return an install hint that names the relevant package (`libsecret-tools` on apt, `libsecret` on dnf) plus the Secret Service requirement.
• Fall back to a Secret-Service-runtime hint plus the exit code when stderr is empty but the call still failed.

The warning flows through:

• `linuxSecretStorage.update` -> `saveCodexCredentials` (`src/utils/codexCredentials.ts:207`)
• -> `persistCredentials` in `useCodexOAuthFlow` (`src/components/useCodexOAuthFlow.ts:103`) where `saved.warning` is now non-empty, so the thrown `Error.message` carries the real reason.
• -> `status.message` rendered by both the `ProviderManager` (`src/components/ProviderManager.tsx:632`) and provider command (`src/commands/provider/provider.tsx:1133`) 'Codex OAuth failed' dialogs.

No dialog wiring change needed; the existing render already uses `status.message`.

Test plan

• `bun test src/utils/secureStorage/platformStorage.test.ts` -> 19/19 pass (4 new "Linux secret-tool Interaction" cases: stderr passthrough, ENOENT install hint, exit-code-only fallback, unchanged success path).
• `bun test src/utils/secureStorage src/utils/codexCredentials.test.ts src/components/useCodexOAuthFlow.test.ts` -> 31/31 pass across 3 files.
• `bun test` -> 2911/2914 pass (3 failing `/export direct filename` tests pre-existing on `upstream/main`, unrelated to this PR).

Notes

Scope is intentionally limited to surfacing the existing-but-discarded failure reason on Linux. The behavior on success and on macOS / Windows is unchanged. macOS `security` CLI errors already surface through their own path, and Windows `update` already routes through `getFailureWarning`.

[jatmn]

#1347 already closed this.