v0.9.14: App-server credential set/clear with source and writable metadata for GPUI providers

[Hmbown]

Why this matters

GPUI Hmbown/codewhale-apps#574 (Linear APPS-48) requires first-run provider setup entirely in the desktop: "UI sees configured/source/writable metadata, never raw secret values in catalog/logs. Environment-managed credentials must not appear successfully overwritten." Today the desktop can show that a provider is configured but cannot write a credential — setup still requires the TUI or editing files.

Current behavior

• GET /v1/providers serves credentialState — a sanitized structural classification (crates/tui/src/runtime_api.rs:6109-6113, "the API never echoes credentials back to callers"). Correct, but read-only.
• No route sets, clears, or verifies a provider credential; there is no credentials write surface in the route table.
• credentials_present on /v1/operate is a readiness flag, not management.

Desired behavior

1. A write route that accepts a credential for a provider, stores it in the existing credential owner, and returns a receipt — never echoes the secret.
2. Per-provider metadata extended or served alongside: source (keychain/env/config/managed) and writable so a client can disable the control with a truthful reason ("managed by environment") instead of letting a write fail late.
3. Clear/revoke for client-owned credentials; environment- or managed-owned credentials refuse with a named reason.
4. Optional verify/probe that reports reachability without exposing the credential.

Acceptance criteria

• Set persists through the existing credential store and flips credentialState on the next GET /v1/providers
• Env-managed credentials refuse overwrite with a named reason; the metadata lets clients show this before submit
• No secret value appears in any response, log line, or error
• cargo test -p codewhale-tui route tests cover set, clear, refused env-managed write, and no-echo

Related: Hmbown/codewhale-apps#574, #6028 (account link / auth model), #5718 (one worker system / Keychain path).

[Hmbown]

claiming: completing the half of this that feat/app-server-routes-0914 (PR #6229) left. That branch already lands the set half — PUT /v1/providers/{id}/key, write-only, 4 KiB cap, control-char rejection, redacted receipt, no GET by design. Missing and in scope here: (1) clear/revoke, (2) source and writable per-provider metadata so a client can disable the control with a truthful reason before submit, (3) env-managed credentials refusing overwrite with a named reason. Files: crates/tui/src/runtime_api/secrets.rs, crates/tui/src/runtime_api.rs (provider serialization + route table), crates/tui/src/provider_readiness.rs, tests in crates/tui/src/runtime_api/tests.rs. Landing on the same branch so it rides PR #6229.

[Hmbown]

Landed on feat/app-server-routes-0914 as 5dd4966f2, riding PR #6229 (Closes #6179).

Acceptance criteria:

• Set persists through the existing credential store and flips credentialState on the next GET /v1/providers — already true on this branch; the integration test now covers the readback through the live config mirror rather than only after a restart.
• Env-managed credentials refuse overwrite with a named reason; the metadata lets clients show this before submit — credentialSource / credentialWritable / credentialWritableReason on GET /v1/providers, and 409 with that same reason from both verbs. The case worth naming is a literal key in a config file: it still wins at request time, so writing the secret store would have reported a success the user could never observe.
• No secret value appears in any response, log line, or error — the clear receipt is asserted to echo no key bytes, and a refusal reason is asserted never to contain the value it refused.
• cargo test -p codewhale-tui route tests cover set, clear, refused env-managed write, and no-echo — four unit tests on the classifier plus one integration test round-tripping set → catalog metadata → clear → readback.

Design notes, in case you disagree with either:

1. Clear went into the shared owner, not the route. crates/config/src/credentials.rs gained clear_provider_api_key and codewhale auth clear now calls it, deleting its inline body and its clear_provider_api_key_from_keyring helper. That surfaced a real CLI defect: the secret-store delete was let _ = secrets.delete(...), so auth clear printed success while the key could still be sitting in the keyring. Both callers now report the backend error, and the route answers 500 naming the slot rather than claiming a revoke it did not achieve.

2. source is a class, never a value. ProviderEntry carries a standing promise to contain no credential, endpoint, path, environment variable or consent-source metadata, and the catalog has a guard test pinning its exact field set — which correctly failed on these additions. The four spellings (secret_store, config, external_auth, none) can never interpolate an env var name or a path, and the guard now asserts that closed vocabulary rather than only the key set, so the field cannot later become a place a value hides.

Not done here: the issue's optional item 4, a verify/probe reporting reachability without exposing the credential. It needs a provider call, so it is a separate slice with a spend question attached.

runtime_api::secrets::tests 4 passed; 0 failed
runtime_api::tests::provider_key* 2 passed; 0 failed
runtime_api:: 258 passed; 0 failed (--test-threads=2)
codewhale-cli --lib 390 passed; 0 failed
fmt clean; clippy clean on CI's allow list