docs(readme): lead with the fee-reality benchmark, rendered from the ledger (#646, partial)

[eaitbrahim]

Partial. #646 also asks for a ~10-second terminal capture of a real run with committed generation tooling. That is unbuilt and the issue stays open for it. This is the numbers half — and the half a GIF would have to agree with.

The README already stated the honest result in prose. #646 asks for it as numbers: the same rule priced twice, before the feature list.

asset	trades	PF at 0% fee	PF at 1.2% taker	break-even fee, measured
BTC	123	1.090	0.333	0.068%
ETH	121	1.458	0.556	0.433%
SOL	92	1.533	0.801	0.751%
ZEC	50	2.713	1.303	1.741%

Four of four profitable with the fee removed. Zero of four survive the fee actually charged. Break-even spans 0.068% to 1.741% — a factor of ~26 across four assets running the same rule on the same clock over the same window.

Rendered, never typed

That is the issue's binding constraint, not a nicety. Every figure is read out of docs/experiments/trials-ledger.jsonl — the hash-chained record of what was actually run — by scripts/render_fee_reality.py and reformatted. A hand-typed benchmark would be a marketing claim wearing a measurement's clothes, in the one block whose entire argument is the difference between those two.

tests/test_fee_reality_block.py fails if the README and the renderer disagree, and separately asserts that every number in the block appears in the ledger row — stronger than "the renderer produced it", because a renderer with a literal baked in would satisfy the drift pin with both sides carrying the same invention.

The caveats travel with the numbers

Pinned by a test, because dropping them would make the block a stronger claim than the measurement supports:

• Every configuration is the argmax of its asset's 144-cell slice, selected on the same data it is re-priced on. Maxima of 144 draws, not edge estimates — the ledger's selection_bias field says so at full strength.
• The bias runs against the finding, which is why the comparison survives it: it inflates the arm that wins with the fee removed, and that arm still dies when the fee is charged.
• Slippage is held at 0.0005 in every cell, so the zero column is zero fee, not zero cost.

Parsing prose is deliberate

The ledger stores the curve as a recorded sentence, because that row was written by the experiment that produced it, and rewriting history to suit a renderer would be the tail wagging the dog. So the parser is strict and every recognition failure is fatal — a parse that silently produced three of four assets would be the quiet half-truth this block exists to refuse.

Two bugs the tests found in the renderer's own output:

• [\d.]+ is greedy enough to swallow the sentence's full stop into the last asset's profit factor. 1.303. is still readable, still wrong, and would have shipped inside a table.
• Fee columns rendered as raw fractions (PF at 0.012), making the reader perform the conversion that produced fix(strategy): price fills at the taker rate, and wire the dormant PBO gate into promotion #247's costing error in the first place.

Verification

9 mutants, 9 killed — and the last took three attempts to write. The column-count guard sat behind the missing-break-even guard, so every input meant to reach it tripped the earlier one instead, and the mutation survived while the test looked like it pinned something.

Full suite 5135 passed / 3 skipped; ruff and mypy clean.