feat: Mix Cover Traffic specification

[chaitanyaprem]

Summary

This PR introduces the Mix Cover Traffic specification — a concrete instantiation of the pluggable cover traffic component defined in Mix Protocol §6.4. The spec defines how mix nodes generate and emit cover packets to achieve sender unobservability.

Key design decisions

• Self-balancing R-slot pool: Cover, locally originated messages, and forwarded packets share a single per-epoch budget R from the DoS protection mechanism. Forwarding naturally consumes ~L/(1+L) of the budget; the remainder is used for cover. No explicit origination rate constraint is needed.
• Self-exit loop paths: Cover packets use loop paths where the originator is the exit node. A dedicated codec string /mix/cover-traffic/1.0.0 identifies returning cover packets during exit processing, handled locally.
• Two strategies: Constant-Rate (RECOMMENDED default) and Poisson-Rate (for Loopix/Nym alignment). The spec includes detailed analysis of why Loopix formal guarantees don't transfer unchanged to this architecture (shared budget violates independence, epoch boundaries break memorylessness).
• Pre-computation as optional optimization: Cover packets MAY be pre-built during epoch N-1 for epoch N, with batched pre-computation as an implementation recommendation.
• Per-hop proof assumption (§4): The budget model assumes per-hop generated proofs. Sender-generated proofs require a different budget model, deferred to future work.
• Pre-scheduled emission timing (§11.3): A future enhancement where all traffic types share a fixed timing grid, eliminating periodic pattern concerns. Only compatible with Constant-Rate. Inspired by blend protocol.

Changes to existing specs

• mix.md §8.6.4: Added step 4 "Internal Protocol Codec Check" between extracting the codec and Exit Layer handoff. This is a generic hook for pluggable components that use internal protocol codecs.
• mix-dos-protection.md §8.2.3: Added OnEpochChange(callback) procedure for epoch boundary notifications to pluggable components.

[jm-clius]

This looks good to me!
Below I made some comments suggesting we underspecify the idea of proof precomputation, mostly to sidestep the complexity that introduces for RLN-based protection mechanisms (not only can a software bug lead to you slashing and deanonymising yourself, but because of root changes you might precompute invalid proofs). However, after reading through everything I agree that we probably want to keep proof precomputation as recommended default. Perhaps we can just RECOMMEND that all proofs be validated (again) before using them?

[AkshayaMani]

Great spec! Left a few comments with questions and suggestions.

[chaitanyaprem]

@AkshayaMani also added an overview section in the spec now.

[Cofson]

Genuinely solid spec, the self-balancing pool model is well argued and the iteration with AkshayaMani has tightened a lot. Three small things worth firming up before draft:

[chaitanyaprem]

I am merging this spec for now, any enhancements can be done as separate PR to update it.