test: bound the amplification, not the machine

[myobie]

three_node_2000_file_continuous_mutation_stays_bounded capped reconciles per second, and derived the scan and persist caps from that same per-second figure. Every bound was a function of how fast the machine happened to be, so the test failed on hardware that was merely quick.

It failed that way twice, and the second one was mine

The cap was 4/s, derived when a persist wrote 72 MB of pretty-printed JSON. #74 made a pass cheaper, more legitimate passes fit the same fixed burst, and I re-derived the cap as 5/s from macOS runs only. Linux CI then produced 5.04/s and turned main red on a run whose behaviour was fine.

Raising it again from one platform's numbers would just move the trap.

Measured on both — the rate moves, the ratios don't

	reconciles/s	scans/reconcile	persists/reconcile
macOS	3.99 – 4.27	2.50 – 2.61	1.86 – 1.95
Linux CI	5.04	2.53	1.81

Scans and persists per reconcile are what amplification means, and they don't depend on clock speed.

What changed

Both are now bounded directly, at exactly the strictness the old per-second forms implied — 112/36 scans and 76/36 persists per reconcile. Nothing is loosened. The failing CI run sits inside both, at 2.53 and 1.81.

The reconcile rate keeps a ceiling, but only as a runaway backstop, far above anything either platform has produced. A feedback loop is orders of magnitude, not a fast laptop.

I proved the new bounds can fail

Tightening the scan allowance makes it fail and name the real figure:

scan amplification: 104 scans for 42 reconciles is 2.48 per reconcile,
over the 1.00 this entry is allowed

And the first version of that message lied. With a tightened numerator it still printed the old limit, because the assertion used the constant while the message hardcoded the number. The allowance now has one source, so the two can never disagree.

Agent: Silber.fabric