feat(vardiff): add in-process simulation framework + baseline regression tests

[gimballock]

Adds a deterministic in-process simulation framework that characterizes
any Vardiff implementation across the operational rate range, and
commits the current algorithm's measurements as a baseline for automated
regression testing.

The "vardiff fires too often on noise" / "vardiff doesn't react fast
enough" conversations have circled the same issues (#396 and adjacent)
without a way to settle questions empirically. This PR adds the missing
infrastructure: any future proposal can now produce a quantitative
delta against a fixed reference.

The finding that motivates this

Before the framework, "is the algorithm too noisy or too sluggish?" was
a matter of opinion. With it, the question is a table:

Reaction sensitivity to a -50% step change (probability of firing
within 5 minutes after the change):

share/min	sensitivity
6	0.70
12	0.55
30	0.33
60	0.16
120	0.09

Higher share rates produce less responsive algorithms — counter to
expectations. The mechanism is mechanical (post-convergence delta_time
grows indefinitely, diluting the post-step signal in the cumulative
window) and surfaced clearly in the data despite taking months of
deployment observation to half-articulate. Full numbers and analysis
in vardiff_baseline.md.

This isn't a fix. It's the measurement that lets the fix be evaluated.

What's in the PR

3 commits, ~2000 LOC plus baseline data:

1. feat(vardiff): inject Clock trait + add_shares trait method
   Minimum API additions to channels_sv2 for testability and
   simulation performance. Production behavior unchanged — existing
   constructors default to SystemClock, the new trait method has a
   default implementation that keeps existing impls compiling.

2. feat(vardiff_sim): in-process simulation framework
   New crate at sv2/channels-sv2/sim/. Per-tick Poisson share
   sampling, five behavioral metrics with percentile distributions,
   50-cell parameterized sweep (5 share rates × 10 scenarios), CLI
   binary for baseline generation, regression test asserting against
   a committed baseline.

3. data(vardiff_sim): design doc + baseline characterization
   The design proposal documenting metric definitions and tolerance
   policy, plus the measured baseline as both TOML (consumed by the
   regression test) and Markdown (for human review).

What the framework measures

Five behavioral attributes, each as a distribution across 1000
independent trials per cell:

Metric	Better is	What it tells you
Convergence time	Smaller	How fast the algorithm settles after cold start
Settled accuracy	Smaller	How close to truth the algorithm lands
Steady-state jitter	Smaller	How often it fires on noise post-settle
Reaction time	Smaller	How fast it responds to genuine load changes
Reaction sensitivity	≈ 1 for real Δ, ≈ 0 for noise	Whether it distinguishes signal from noise

Per-metric tolerances are asserted automatically against the checked-in
baseline. Failed assertions identify the cell and metric with specific
baseline-vs-current numbers. Mid-range Δ values (10-25%) are reported
but not asserted — that's where legitimate algorithmic tradeoffs live
and a reviewer should judge by looking at the full delta.

How to run

From sv2/channels-sv2/sim/:

# Fast unit tests (~1 second)
cargo test

# Generate a fresh baseline (~5-15 seconds)
cargo run --release --bin generate-baseline

# Run the slow regression test (~5-15 seconds; #[ignore]-d by default)
cargo test --release --lib -- --ignored

What this enables

For any future vardiff proposal:

1. Implement the new algorithm as a Vardiff impl
2. cargo run --release --bin generate-baseline to produce comparable
   measurements
3. Diff against the committed baseline
4. Make the case with numbers

No more "I think this is better." Instead "this changes p50 jitter from
X to Y at 12 spm, at the cost of p90 reaction time going from A to B."

Where to look in this PR

• Design proposal (architecture, metric definitions, tolerance
  rationale): sv2/channels-sv2/sim/VARDIFF_SIMULATION_FRAMEWORK.md
• Crate README (usage, output interpretation, baseline-update
  workflow): sv2/channels-sv2/sim/README.md
• The current algorithm's measured baseline:
  sv2/channels-sv2/sim/vardiff_baseline.md

What this PR is NOT

• Not an algorithm change. VardiffState behavior is unchanged.
  The only public-API additions are Vardiff::add_shares (with a
  default impl) and the Clock trait. Production code defaults to
  SystemClock and behaves identically to before.
• Not a recommendation about share rate defaults. The baseline
  data suggests 12-30 spm is the operational sweet spot, but this
  PR doesn't touch any defaults.
• Not a CI workflow. The regression test works locally but needs
  a GitHub Action to be a true CI gate. Follow-up.

Open follow-ups

• Wire cargo test --release --lib -- --ignored into CI on PRs
  touching vardiff/* or the sim crate.
• Bump channels_sv2 5.0.0 → 5.1.0 once the workspace lockfile
  situation allows (the trait-method addition is technically a
  minor-version semver change). TODO comment in Cargo.toml tracks
  this.
• Investigate the reactivity-degrades-with-rate finding. The framework
  surfaces the problem; fixing it is a separate proposal that this
  framework will be the right tool to evaluate.

Test plan

• cargo test -p channels_sv2 --lib vardiff — 17 tests, all pass
• cargo test from sv2/channels-sv2/sim/ — 53 fast unit tests
• cargo test --release --lib -- --ignored from sim/ — slow
  regression test passes against committed baseline
• cargo run --release --bin generate-baseline — reproduces the
  committed vardiff_baseline.toml byte-for-byte at the same seed

[gimballock]

The ask to get this simulator off the ground is a new trait to swap out the system clock with a MockClock, and the addition of a new public method to the vardiff trait. These changes are isolated to the first commit.

[gimballock]

The first row here shows results of the convergence time test for the the default case (6 spm).
The convergence times are between 10 and 25 minutes, with total failures to converge (w/in 5m of simulated time) occurring 17% of the time!

the next few rows describe the results for faster share rates. the most extreme times (25m reduces to 15m) and the total failure cases generally disappear around 30 spm.