docs(bench): correct the during-save tail record -- CLOSED (794ms -> 30ms), not a 40x loss

[ELares]

Why

The public benchmark docs still describe the pre-#742 world and materially undersell the product.

docs/bench/TAIL_LATENCY.md's measured record was committed 2026-07-23 14:20; PR #742 (the fix) merged 18:52 the same day. So every IronCache tail in that record is pre-fix. The post-fix c7g confirmation was run and posted on #676 — it just never reached the docs.

Most visible symptom: the README described the during-snapshot tail as "a known limitation at a memory-bandwidth floor", and TAIL_LATENCY.md's verdict read "~40x worse than Dragonfly".

The real numbers (from the #676 confirmation, same config)

	p99	p99.9
no-save baseline	12 ms	21 ms
during base save (pre-#742)	~640 ms	~794 ms
during base save (post-#742)	12 ms	30 ms

vs the same pinned competitors: Dragonfly 19 ms, IronCache 30 ms, Valkey 510 ms, Redis 719 ms — from worst-in-class into Dragonfly's class.

Files

• TAIL_LATENCY.md — new CURRENT record on top; old record retitled "Superseded: PRE-perf(#676): spawn __ICSAVE off the drain loop to fix the during-save HOL block #742" with a warning that its analysis attributes to save cost what was actually a scheduling defect (the dataset-scaling table and its "~4.3 ms of datapath stall per MB" were measuring how long the HOL block lasted). Competitor numbers and the save wall-time characterization remain valid, so it's kept for provenance.
• README.md — the stale "known limitation" claim corrected.
• docs/PRODUCTION_READINESS.md — the "291ms, competitive but not category-leading" line updated.
• docs/design/PERSISTENCE.md — 291ms marked historical (it's the perf: per-slot Arc copy-on-write snapshot isolation, uncontended datapath during a save (#576 core) #588 Arc-COW change alone), and the "FUNDAMENTAL memory-bandwidth-headroom tradeoff" claim marked SUPERSEDED — disproven twice by measurement (the perf(#676): pace the base-save persist read to leave datapath bandwidth headroom #740 pacer was refuted on c7g and reverted; the 1-shard-vs-8-shard ablation showed the bigger save stalling ~60x less).

No new measurement was taken — the numbers already existed on #676. This only makes the shipped docs match the merged code.