test(e2e): calibrate the long-query fixture to the host instead of a fixed size - #226

Problem

The full-suite release checkpoint (run 37178372590, job Tests (full)) fails one test: reactive::agent_receives_deltas_while_its_own_long_query_runs panics with fixture too fast to show blocking: 469.349585ms.

Why the query ran only ~469 ms

The runner is faster than the fixed fixture assumed. No engine change caused it.

• It failed from the start. The previous full run (37154966559) was at 3554c98 (feat(ws): request IDs, per-connection pipelining, deadlines and real cancellation (#132, #136 part) #214), the commit that added this test, before the wildcard fix fix(ir): make each '_' in a rule body a fresh anonymous variable #219 and shared evaluation feat(protocol): share standing-query evaluations across identical subscriptions #223. It failed the same way at 472 ms. Same runner class (blacksmith 4 vCPU), same time within 1%, so fix(ir): make each '_' in a rule body a fresh anonymous variable #219 and feat(protocol): share standing-query evaluations across identical subscriptions #223 did not change the query's speed.
• No caching. Locally, three consecutive runs of ?edge(X, Y), edge(Y, Z), edge(Z, X) on one connection take the same time (side 14: 720/647/647 ms; side 20: 3.3/2.97/2.97 s), and each correctly returns 0 rows. A bipartite graph has no odd cycle, so the query is fast for no correctness reason.
• The fixture was undersized. The in-process twin of this test (tests/ws_pipeline_tests.rs) uses side 20 for release builds; this e2e test used side 14, about 3–5× less work. The join cost grows faster than side³ (local: 14 → ~0.65 s, 20 → ~3.0 s, 24 → ~6.5 s). That leaves ~0.47 s on the CI runner, just under LONG_QUERY (500 ms).

Fix

The test now calibrates the fixture to the host instead of using a fixed size:

• Node numbering. Left nodes are now even and right nodes odd, so a larger graph only adds edges.
• Calibration. calibrate_long_query runs TRIANGLES on a probe connection. Until it takes at least 2 × LONG_QUERY, it grows the side by the cube root of the shortfall, commits the extra edges and probes again. A deadline-exceeded probe counts as long enough. The side is capped at 64, and if the cap is hit the test fails loudly.
• Sample naming. The calibrated side goes into the latency sample's fixture name (bipartite_triangles_<side>).

Not changed: DELTA_BUDGET (250 ms), the delta latency assertion, ran >= LONG_QUERY, the delta-before-result ordering check and the empty-result check. The cancel test reuses the same base fixture (side 14) without calibration, since it only needs the query to outlive 100 ms.

Validation

• make e2e-reactive ×5 locally: 14/14 passed each run. Calibration settled on side 16 every time, and writer-to-delta latency was 1.6–2.3 ms.
• Faster-host simulation. I temporarily started at side 6 so calibration had to take several steps. It grew to side 21 and passed (change reverted).
• cargo clippy --release --test e2e_reactive -D warnings and cargo fmt --check are clean.