template: add Threat Model & Security Requirements section

[fryorcraken]

Summary

• Adds a new ## 🛡️ Threat Model & Security Requirements section to RFPs/RFP-000-template.md listing common privacy/security scenarios grouped by adversary class (O on-chain observer, A active attacker, C malicious counterparty, S sequencer, F malicious/buggy client, X external identity correlator). Each scenario has a stable code so other documents can reference them, and protocol-specific scenarios extend the same numbering per RFP.
• Adds appendix/logos-stack-trust-assumptions.md as a dated snapshot (2026-04-28) of the five component FURPS published at roadmap.logos.co, pulled from logos-co/roadmap@v4. The appendix quotes each relevant FURPS item verbatim, then distils a Stack-wide trust assumptions an RFP can rely on list and a Stack-wide non-guarantees an RFP must not assume list. Notable non-guarantees: no anonymous transaction submission at the network layer, no mempool/pre-confirmation privacy, no anonymous indexer RPC queries, no off-chain LEZ-state privacy, no sequencer-level censorship resistance.
• Retargets Supportability item 9 (privacy and anonymisation properties document) so it must address every scenario in the new Threat Model section.

Why draft

Open for discussion before applying the new section to the existing RFPs (001, 002, 003, 004, 008, 012, 015, 016). Each of those will get its own follow-up PR adding protocol-specific scenarios under the relevant adversary class.

Specific items worth feedback before merging:

• Adversary class set. S (sequencer) is included because the appendix found that LEZ FURPS does not commit to non-censorship or non-correlation against the sequencer. Reasonable, or fold into trust assumptions?
• O-5 requires the SDK/mini-app not to issue RPC queries that re-link ephemeral accounts. This is non-trivial to implement and may be a meaningful new requirement on every RFP. Acceptable bar?
• Out-of-scope listing requirement. Proposals must enumerate out-of-scope scenarios with rationale rather than omit them. Adds proposal length but makes review easier.
• Snapshot freshness. The appendix is dated; it should be re-validated before each new batch of RFPs uses it. Worth a follow-up scheduled agent?

Test plan

• Review the adversary class set and stable codes
• Verify the FURPS quotations against the live roadmap pages
• Confirm the Supportability item 9 rewording does not invalidate any existing RFP's privacy doc plan
• Decide whether the appendix lives under appendix/ (current) or under RFPs/ next to the template
• Plan the per-RFP follow-up PRs that add protocol-specific scenarios

🤖 Generated with Claude Code

[fryorcraken]

@kaiserd to provide feedback as this attempts to address his concerns.