spec(automation): tri-wallet-chains v2 -- a budget on the two doors without a person #8315

Review on gHashTag/999-multibots-telegraf#3952 (t27-bees): /api/tri/wallet/message and /api/tri/wallet/propose are public (no person) and have no rate limit; a spray of proposals costs a signature check each.

v2 of specs/automation/tri-wallet-chains.t27 (v1: #8293, #8294):

• each caller address: 30 calls per 60 s window, in memory only, at most 10000 callers tracked; past it 429, nothing parsed or written;
• /propose looks the nonce up before it checks a signature (checks_signature): a dead nonce costs one key lookup, no curve arithmetic.

Done when the spec is merged and the host (999) vendors v2 and enforces both, with tests.

User Scenarios

• Given a caller address has made 30 calls to /api/tri/wallet/propose within a 60-second window, When the 31st call is made, Then the server responds with 429 and does not parse or write the request.
• Given a caller address sends a proposal with a dead nonce to /api/tri/wallet/propose, When the request is processed, Then the nonce lookup occurs before signature verification and no elliptic curve arithmetic is performed.

Requirements

• FR-001: The spec MUST enforce a rate limit of 30 calls per 60-second window per caller address, tracked in memory with a maximum of 10000 callers.
• FR-002: The spec MUST return 429 Too Many Requests when the rate limit is exceeded, without parsing or writing any request data.
• FR-003: The spec MUST require that the /propose endpoint looks up the nonce before checking the signature (checks_signature), so that a dead nonce incurs only a key lookup and no curve arithmetic.

Success Criteria

• t27c specs/automation/tri-wallet-chains.t27 exit 0
• 5 tests pass for specs/automation/tri-wallet-chains.t27

Boundary

• specs/automation/tri-wallet-chains.t27