bench-regression p95 gate is red on release runs: threshold measured on different hardware than CI

[snchimata]

bench-regression failed on the v0.4.1 release run and will keep failing on
every tag push until the threshold is re-baselined:

REGRESSION: structured_json_under_2mb_p95_ms regressed: 2664.682ms > 2500.000ms
error: bench failed, to rerun pass `-p tokenfold-core --bench compression_bench`

Run: https://github.com/snchimata/tokenfold/actions/runs/32210070277/job/95940853619

This is not a code regression

Four independent checks:

1. git diff 0e68d24..v0.4.1 -- crates/tokenfold-core/src/ crates/tokenfold-core/benches/
   is empty — the 0.4.1 change set touched no core logic and no benchmark code.
   Its only core-adjacent edit is the [[example]] declaration in Cargo.toml.
2. The threshold value is unchanged at 2500.0 since v0.4.0.
3. compression_bench.rs's only diff since v0.4.0 is a doc-comment rewrite.
4. v0.4.0's release run passed the same gate — consistent with variance around a
   boundary, not a step change.

Root cause: hardware mismatch

benches/THRESHOLDS.toml records the baseline as measured on
AMD Ryzen 7 9800X3D (8c/16t), 31GB RAM, Windows at 1693.855ms, with the
threshold set to 2500.0 for ~1.48x headroom. bench-regression runs on a shared
ubuntu-latest runner, which is both slower and highly variable.

The file already anticipates exactly this:

Thresholds carry ~1.3-1.5x headroom over the measured baseline for runner
variance; tighten once bench-regression has run on a dedicated, fixed-spec
CI runner.

It also notes p95 here is "dominated by TiktokenEstimator::o200k_base()
reloading BPE ranks on every compress() call" — an I/O-and-parse cost that
scales with runner speed rather than with anything in the compression path.

Why it matters even though it doesn't block

The job is continue-on-error: true (release.yml#L76),
so the release completed normally. The problem is a permanently-red gate: once
people learn to ignore it, it stops catching the real regression it exists for.

Options

1. Re-baseline on the CI runner class — measure ubuntu-latest p95 over
   several runs, set the threshold from that distribution, and record both the
   hardware and the sample size in THRESHOLDS.toml.
2. Move bench-regression to a dedicated fixed-spec runner — what the
   file's own comment recommends; the only option that makes a tight threshold
   meaningful.
3. Cache the estimator across compress() calls — attacks the measured
   dominant cost rather than the threshold, and is a real latency win for
   callers, not just a green gate.

Please don't just raise the number to make it pass — that discards the signal
without recording why.