Formal threat model and mitigation for anonymous-voting key-holder compromise

[Ehonrie]

Difficulty: Research-Required
Category: Security

Context: The current anonymous-voting scheme concentrates total decryption power in whoever holds the single generated RSA private key — they can decrypt individual votes early, sell influence over the outcome, or simply lose/leak the key, invalidating anonymity guarantees retroactively for that proposal. This issue asks for the missing artifact underlying several related implementation efforts (threshold key management, ZK range proofs, reveal timelocks): a rigorous threat model.

<!-- Audits/anonymous-voting-threat-model.md (new) -->
<!--
!todo: Enumerate all parties (voter, key holder, contract, RPC operator, dapp operator)
       and, for each, what they can observe/do/forge given ONLY the current codebase
       (crypto.ts, anonymousVoting.ts, contract_dao.rs's anonymous voting entrypoints).
!todo: Rank threats by (a) likelihood given realistic operational practices for this
       project and (b) impact (individual vote deanonymization vs. tally manipulation
       vs. denial of reveal).
!todo: For the top-ranked threat, implement the strongest PRACTICAL mitigation given
       this codebase's constraints (browser WebCrypto, Soroban resource limits) —
       this may be a scoped-down threshold-crypto or timelock approach, or a different,
       more immediately deployable control (e.g. mandatory key-holder rotation per
       proposal, committee-witnessed key generation ceremony) if full threshold crypto
       is too large for one deliverable.
!todo: Reference: NIST SP 800-30 (risk assessment methodology) as a structuring guide.
-->

What contributors need to know:

• Problem: this is deliberately the "figure out what actually matters most" issue underlying the cluster of anonymous-voting security concerns across this project — a contributor should read the existing Audits/tansu-soroban-security-assessment.md before starting.
• Related code: crypto.ts, anonymousVoting.ts, contract_dao.rs's anonymous-voting functions, get_anonymous_voting_config.
• Suggested approach: produce the threat model document first as a standalone deliverable (reviewable on its own), then implement only the single highest-priority mitigation it identifies — resist scope creep into "solve everything."
• Acceptance criteria: a merged threat-model doc under Audits/; one concrete, shippable mitigation implemented and tested, explicitly justified by the doc's own risk ranking.

[OluRemiFour]

I've reviewed the issue and understand the requirements. I'd love to work on this and submit a clean PR that meets the acceptance criteria.