[MEDIUM] PII scan fallback uses window.confirm; API error text may leak key substrings

[matthewod11-stack]

Description

Two small privacy / UX issues on error paths:

1. PII scan fallback fail-OPEN via window.confirm — if scanPii throws, ConversationContext.tsx:326-336 pops a native window.confirm("...Send anyway?"). For a privacy-forward HR product, the right default is to fail closed (reject send) with an in-app error, not delegate the decision to a native blocking dialog.

2. Raw upstream API errors surfaced to UI — chat.rs:221,311 formats errors as format!("HTTP {}: {}", status, parsed) which can echo provider error messages containing partial API key substrings (sk-ant-..., AIzaSy...). Low-probability key leak to UI / logs / support emails.

Current State

• src/contexts/ConversationContext.tsx:326-336 — window.confirm on PII scan failure
• src-tauri/src/chat.rs:221,311 + providers' parse_error_response — passthrough of raw API error body

Suggested Fix

• Replace window.confirm with an in-app error state + retry button. Fail closed by default.
• Add a regex scrub in the Rust error formatter: if error text matches sk-[A-Za-z0-9_-]{10,} or AIzaSy[A-Za-z0-9_-]{20,} or other known key prefixes, replace with [API_KEY_REDACTED].
• Apply the scrub in a central helper called by all three providers' error parsers.
• Add tests: error containing sk-ant-abc123... → UI-facing string has [API_KEY_REDACTED].

Verification

• cargo test + npm run type-check pass
• Manual: cause a PII scan failure (disconnect Rust, etc.) → in-app error shown, send blocked.
• Manual: trigger a 401 from a provider with a bad key → error message does not contain the key string.

Automation Hints

scope: src/contexts/ConversationContext.tsx, src-tauri/src/chat.rs, src-tauri/src/providers/*.rs
do-not-touch: pii.rs
approach: add-declarations
risk: low
max-files-changed: 5
blocked-by: none
bail-if: none

Priority

Medium — two small but real privacy / UX issues.