Tighten v1 security invariants and define the trusted-computer boundary

[BenWestgate]

Problem

The v1 security documentation is close, but the normative contract is not fully consistent.

docs/security/invariants.md currently says:

Secrets stay out of arguments, logs, ordinary output, and public transfers.

That is too broad: create, secret, and xprv intentionally emit secret material as part of their documented behavior. The detailed security model already uses the more accurate rule that normal output must not reveal secrets unintentionally.

The documentation also tells users to use a "trusted computer" without defining that boundary precisely enough for security-critical software.

Finally, CLI help notes that some commands accept piped input. Stdin support is useful, but users should not infer that embedding a seed/share directly in a shell command (for example with echo) is safe, because shells may retain command text in history or other logs.

Proposed changes

Define trusted computer

Use an operational definition aligned with Bitcoin Core's own security documentation:

A trusted computer is a computer under the operator's exclusive control that is not known or suspected to be compromised, and whose operating system and other software running during the operation are trusted. For codex32 wallet operations, this includes the Python environment, codex32, bitcoin-cli, Bitcoin Core, and its relevant configuration. An offline trusted computer must remain disconnected from every network before, while and after handling private recovery or signing material.

Also state explicitly that wallet encryption, application permissions, or RPC authentication do not make a compromised or otherwise untrusted computer safe for handling recovery material.

Make the secret-output invariant literal

Rewrite the invariant so it prohibits unintended disclosure rather than all ordinary output, and enumerate the commands/channels that intentionally reveal secret material.

Clarify stdin/piping guidance

Keep stdin support, but warn users not to place recovery material directly in shell command text because shell history, process tooling, terminal logging, or wrappers may retain it.

Acceptance criteria

• docs/security/invariants.md, docs/security/model.md, SECURITY.md, CLI help, and the user guide use consistent terminology.
• "Trusted computer" has one explicit definition.
• The normative secret-output invariant accurately describes intentional and unintentional secret output.
• Secret-emitting commands are clearly identified.
• Stdin guidance distinguishes safe prompted/redirected input from putting recovery material directly in command text.
• Existing tests/documentation checks are updated to enforce the revised contract where practical.