Threat model: state that the app's webview is part of the trusted base #818

Goal

THREAT-MODEL.md says plainly that the app's own user interface (the webview) is trusted: code running there can do everything the user can do in the app. Readers can see which protections keep untrusted code out of the webview, and that this is an accepted design decision.

Context

• THREAT-MODEL.md describes what the AI sees (§1), redaction (§2), storage (§3), network connections (§4, incl. the Content Security Policy connect-src 'self' ipc: enforced by apps/smart-ssh-community/tests/network_boundary.rs), confirmation boundaries (§5) and residual risks (§6). It does not say who is trusted on the inside of the app.
• In fact the webview belongs to the trusted base:
  • The app's own Tauri commands (crates/app-shell, registered in crates/app-shell/src/lib.rs, ~170 commands) are not restricted per command by the capability files; the webview can call all of them, e.g. terminal input, the answer to a pending confirmation, MCP token regeneration.
  • store:default (apps/smart-ssh-community/capabilities/default.json) lets the webview write settings.json directly, which holds safety-relevant settings such as "Always confirm on red risk" (read by crates/app-shell/src/risk_second_opinion.rs:48-60).
• This is consistent with the design (the UI is the user's hand), but undocumented. The protections that keep foreign code out of the webview exist: CSP default-src 'self'; script-src 'self' (apps/smart-ssh-community/tauri.conf.json:31), no remote content loaded, server and AI content rendered as text, not as HTML.

Requirements

1. New short subsection in THREAT-MODEL.md (in §5 before the table, or as its own subsection "Who is trusted inside the app"): the webview that renders the app's UI is part of the trusted base. Code running in it acts with the user's authority: it can type into terminals, answer confirmations and change settings, including safety settings. The confirmation boundaries of §5 protect against the AI and external tools, not against code in the webview.
2. List the protections that keep untrusted code out of the webview, each with a link to the backing file: CSP (tauri.conf.json), the network-boundary test, no remote scripts/fonts (§4), content from servers and AI shown as text (link the code or spec that guarantees it; verify before writing — if a statement cannot be backed by code, leave it out).
3. New bullet in §6 "Known residual risks": a script-injection flaw in the UI would equal full control over connected sessions and the safety settings; accepted because the UI is the user's own interface; planned hardening: safety settings changed only through backend commands (no issue reference needed).
4. Every statement links the spec, ADR or code that backs it (rule at the top of the document).

Acceptance Criteria

• THREAT-MODEL.md contains the trusted-base statement, the list of protections with links, and the residual-risk bullet.
• Every link in the new text resolves to an existing file (checked in the PR).
• No statement claims a protection the code does not have (each one verified against the linked file; noted in the PR description).
• Documentation only; no code or CI change.

Technical Notes

• Security documentation: keep the tone of the existing document (plain, checkable statements). Describe the trust boundary and the protections; do not describe how one would exploit a UI flaw.
• Read .claude/skills/smart-ssh-coder/references/security-invariants.md to keep the wording consistent with the stated invariants.

Spec impact: none

Related Work

• Write THREAT-MODEL.md, including the limits of pattern-based redaction #17 (THREAT-MODEL.md), Only upload local files the user picked or dropped, not any path the webview sends #89 (only upload local files the user picked, not any path the webview sends), Suppress the WebView context menu ("Reload") in release builds; add "Refresh" to the file browser's empty-space menu #629