i18n: propagate desktop API-key/storage security-doc corrections to 14 remaining locales

[qnbs]

Summary

PR #352 corrected several stale/false security claims in `locales/en/help.json` (see also `docs/IDB-ENCRYPTION.md`, `docs/SECURITY-THREAT-MODEL.md`). During Wave 0 review-thread remediation (2026-08-18, see `docs/cef/ROADMAP-CEF-DESKTOP-MIGRATION.md` §65 and PR #352/#365/#366's review threads), these corrections were propagated to all 5 production-tier locales (en/de/es/fr/it) but not yet to the remaining 14 (ar, he, el, ja, zh, pt, fa, fi, sv, hu, is, eu, ru, ko), per this repo's established two-tier i18n practice (/i18n-key skill covers the 5 production locales; the rest are updated manually afterward — see CLAUDE.md § i18n).

What was fixed in en/de/es/fr/it

1. Removed a false Stronghold claim — help.docs.tauriDesktop.content claimed tauri-plugin-stronghold can store the IDB passphrase; no such dependency exists anywhere in the codebase. Already mechanically removed from all 13 locales that had it (this part of the fix is already propagated everywhere: de, el, eu, fa, fi, hu, is, ja, ko, pt, ru, sv, zh).
2. Corrected the API-key encryption mechanism description — several Help entries claimed API keys are "PBKDF2-encrypted before being stored in IndexedDB." This is wrong: services/storage/idbKeyStore.ts uses a random, non-extractable generated key — no passphrase, nothing to derive, no PBKDF2 involved. PBKDF2 is only used for the opt-in project-data-at-rest passphrase (a different, unrelated feature) and for collaboration E2E encryption.
3. Scoped "never sent to any WorldScript server" claims with the Claude/Anthropic exception — on the web/PWA build, Claude requests relay through WorldScript's own stateless serverless proxy (never logged) since Anthropic blocks direct browser requests; desktop calls Anthropic directly like every other provider. The blanket "never transmitted" claim was misleading for this one case.
4. Scoped "all data lives in your browser's IndexedDB/OPFS" claims to Browser/PWA — on the Tauri desktop build, project data lives in local files under the app's data directory, not the browser storage APIs.

Affected keys (same 4-5 per locale): help.aiStudio.providers.content, help.faq.api.content, help.faq.privacy.content, help.gettingStarted.desktop.content, help.docs.privacySecurity.content.

Remaining work

Apply the equivalent corrections (2-4 above; the Stronghold removal is already done everywhere) to:

• ar (RTL stub — verify actual content vs. English-fallback status first)
• he (RTL stub — verify actual content vs. English-fallback status first)
• el
• ja
• zh
• pt
• fa
• fi
• sv
• hu
• is
• eu
• ru
• ko

Use the corrected English/German/Spanish/French/Italian text (git history on locales/{en,de,es,fr,it}/help.json, commits from 2026-08-18) as the reference for what each locale's equivalent sentences should say. Run `pnpm run i18n:check` after editing to rebuild bundles and verify key parity.

Not attempted in this pass: translation quality/accuracy risk for security-sensitive content in languages without a confident reviewer in this session (particularly CJK, RTL, and Cyrillic scripts) outweighed doing a rushed mechanical find-replace.

[qnbs]

Additional key found during the correction-loop pass (PR #383): help.advanced.encryption.content also had two stale claims fixed in en/de/es/fr/it — (1) "changing or disabling encryption is unavailable" (Phase 4 shipped both disable and passphrase rotation), and (2) missing Browser/PWA scoping (a desktop reader would wrongly assume this protects their project files too). Same remaining-14-locales scope applies to this key as well.

[qnbs]

Live status audit against main 34b83a22: all five affected help keys are present in all 14 remaining locale files, and i18n:check/quality passing proves parity and placeholders only. The corrected security wording is established in en/de/es/fr/it, but the remaining 14 locale values have not been semantically reviewed against those corrections; mechanical scans still show legacy security concepts in affected translations and cannot prove that the claims are correctly scoped. #382 remains OPEN. Closure requires a locale-by-locale review of the five affected keys, corrected translations or an explicit reviewed fallback decision, followed by the existing parity/content checks.

[qnbs]

PWA acceptance linkage: #478 now explicitly includes truthful browser/PWA security/privacy messaging as a first-class quality requirement. The remaining locale corrections here therefore feed a release invariant, not merely documentation cleanup: provider routing (especially Claude proxy), browser IndexedDB/OPFS versus native filesystem storage, API-key protection versus project-data encryption, and local-vs-cloud AI claims must remain semantically distinct across locales. Please preserve that distinction rather than compressing the translations into broader "everything stays local/encrypted" wording.

[qnbs]

PWA/native program reconciliation — 2026-08-24

Keep this issue as the security/privacy locale-wording authority. #478/#489 diagnostics, #482 storage UX, #483 AI execution truth, and #485 update/recovery UX must consume the corrected terminology rather than introduce renderer-specific security claims.

In particular, UI/docs must continue to distinguish credential storage, project-data encryption, native R-15 protection, collaboration crypto, browser origin privacy, cache semantics, and local-vs-cloud AI routing. Translation parity is not permission to simplify these into misleading umbrella claims.