Add ratchet counter DoS protection and RotateChannelKey authorization

[intendednull]

Closes #109
Closes #110
Progresses #108

Summary

This PR addresses two critical security findings from the code quality review tracked in #108:

1. [state] RotateChannelKey has no permission or membership check #109: Restricts RotateChannelKey events to users with ManageChannels permission and adds defense-in-depth membership validation. Before this, any outsider with a valid signature could inject arbitrary encrypted-key bytes into ServerState.channel_keys.
2. [crypto] Bound ratchet_counter in open_content to fix CPU DoS #110: Adds DoS protection against unbounded ratchet counter derivation by introducing a bounded decryption function with a configurable lookahead window. Before this, one malformed packet with ratchet_counter = u64::MAX could freeze every recipient's CPU for ~584 000 years on a single core.

Key Changes

Crypto Module (crates/crypto/src/lib.rs)

• New error variant: RatchetCounterOutOfRange { claimed, max } to report when a sealed packet's counter exceeds acceptable bounds
• New constant: MAX_RATCHET_LOOKAHEAD = 1024 defines the maximum counter advance a receiver will accept before AEAD verification
• New function: open_content_bounded(sealed, key, current_counter) performs bounded decryption:
  • Rejects packets with ratchet_counter > current_counter + MAX_RATCHET_LOOKAHEAD before any HKDF work
  • Prevents CPU DoS where an attacker could force u64::MAX iterations of key derivation
  • Allows legitimate catch-up within the lookahead window
  • Bypasses bounds check when ratchet_counter == 0 (backwards compatibility)
• Refactored: open_content() now wraps open_content_bounded() with current_counter = 0 for backwards compatibility
• Comprehensive tests: Five regression tests covering huge counter rejection, lookahead boundary enforcement, legitimate catch-up, shim rejection above lookahead, and legacy zero-counter behavior

State Module (crates/state/src/materialize.rs)

• Permission check: Added RotateChannelKey to the list of events requiring ManageChannels permission
• Defense-in-depth: Added explicit membership validation in apply_mutation for RotateChannelKey events to reject non-members even if permission checks are bypassed
• Documentation: Updated comments to reflect that encryption events now have permission requirements

State Tests (crates/state/src/tests.rs)

• Three regression tests for [state] RotateChannelKey has no permission or membership check #109:
  • rotate_channel_key_by_outsider_is_rejected: Verifies outsiders cannot inject key material
  • rotate_channel_key_by_member_without_manage_channels_is_rejected: Verifies permission enforcement
  • rotate_channel_key_by_admin_still_works: Sanity check that legitimate admins can still rotate keys

Implementation Details

• The ratchet counter bounds check uses saturating_add to safely handle current_counter near u64::MAX
• The lookahead window (1024 messages) is deliberately generous to allow receivers to catch up after missing bursts
• The zero-counter special case preserves backwards compatibility with legacy sealed content that doesn't use ratcheting
• Permission checks are layered: required_permission() provides the primary gate, and membership validation provides defense-in-depth
• Neither code path has production callers today — the features are dormant at the emission level, so these fixes pre-empt live vulnerabilities rather than patching an exploited surface

Test plan

• cargo fmt --check — clean
• cargo clippy --workspace -- -D warnings — clean
• cargo test --workspace — 0 failures (30 crypto tests, 155 state tests, all other crates green)
• cargo check --target wasm32-unknown-unknown — clean for all library crates
• Five new crypto regression tests pass in < 10ms total (bounds check returns instantly even for u64::MAX)
• Three new state regression tests pass

https://claude.ai/code/session_011cBQL95mF4j2DGCeLgxrsr