docs: Define the supported threat model #212

Problem

CipherStick makes security and privacy claims without one supported threat model defining the project-specific trust boundaries, assumptions, and non-goals. Reviewers need to distinguish risks introduced by CipherStick from risks inherited unchanged from Tails or Bitcoin Core.

Scope

Focus the threat model on the narrow custom installer and handoff workflow:

• Execution and authentication of CipherStick bootstrap and update packages.
• Bitcoin Core download, signer, release-verification, and metadata boundaries chosen by CipherStick.
• Persistent Storage configuration, permissions, and state changes made by CipherStick.
• The fresh-Tails handoff boundary and explicit user-selected transfer of project or blockchain data.
• Supported deployment assumptions, including a dedicated Tails USB.
• Physical access, unlocked-session, endpoint-correlation, pruning/IBD, shutdown, and secret-loss risks only where CipherStick changes them or makes a related claim.
• Explicit non-goals, including coercion resistance and guarantees of leaving no network trace.

Reference upstream Tails and Bitcoin Core documentation for inherited risks rather than duplicating their threat models. The removed custom wallet and removed Sparrow integration are outside the target runtime. python-codex32 has its own security review; Bails owns only the separate installation/launch boundary introduced by #215.

Acceptance criteria

• Every CipherStick security claim maps to an installer or handoff property.
• Project-specific assumptions and residual risks are visible before installation.
• Inherited upstream risks are referenced without being presented as CipherStick-specific.
• Implemented, experimental, planned, and unsupported controls are distinguished.