diff --git a/FIDELITY.md b/FIDELITY.md
index 25d5139..8bbc4fa 100644
--- a/FIDELITY.md
+++ b/FIDELITY.md
@@ -27,7 +27,7 @@ The 500-page run relaunched at the end of round 167 (both crash fixes in place)
 - **Fixed**: `LoadFontFaces`'s per-slot loop now fires every DISTINCT candidate concurrently (deduped by a new `srcsKey` — the same src list parsed twice, e.g. the same stylesheet named twice, still fetches once) and picks the lowest-declaration-order success after they all finish, instead of walking the list waiting for each failure in turn. `e.Client`'s existing per-host semaphore (`maxPerHostConcurrency`, round 57/58, left at 2 — the round-152/153-measured value, re-confirmed still right for Wikimedia, not re-opened by this round) still bounds real network concurrency, so this is a bounded, not unlimited, speedup: candidates now batch through that cap rather than waiting out every predecessor's own fetch one at a time.
 - **Test**: `TestLoadFontFacesTriesSlotCandidatesConcurrentlyNotSequentially` — a local server with 5 slow-then-500 candidates plus 1 fast-success candidate declared LAST in one slot, deliberately shaped like the live cs.cmu.edu case. Stash-verified: ~460ms with the fix (bounded by the per-host cap, confirmed deterministic across 3 runs) vs ~760ms on the unfixed code (sequential), a measured, reproducible, and reliably-separated difference, not assumed from the live site alone (which could not be cleanly re-measured after this round's own repeated testing had, by its own escalating response times, visibly triggered the origin's own rate-limiting/anti-scraping defenses — an honest limitation of live-site verification for this specific fix, mitigated by the deterministic local-server test instead).
 - **Coverage**: `fontfaces.go`'s `LoadFontFaces` and the new `srcsKey` both land at 100%; the top-level `engine` package moves from a pre-existing 96.1% baseline (confirmed via `git stash`, unrelated gaps) to 96.2% — no regression.
-- **Not fixed this round, flagged honestly**: `unicode-range` itself remains unmodelled (this fix removes the serialization cost of the collision, not the collision — all five rules still compete for one slot, and whichever succeeds first wins for the WHOLE family+weight regardless of which glyphs it actually covers; a page relying on Font Awesome's REAL icon-subset behavior could still render the wrong glyphs, just not slowly). The other ~9 slow pages from this round's bench run were not individually profiled — `cs.cmu.edu`'s own shape (several same-weight legacy-shim font-face rules hitting a consistently-erroring endpoint) is a plausible but UNCONFIRMED shared cause; re-measuring the full 500-page corpus once this fix lands is the natural next check.
+- **Not fixed this round, flagged honestly**: `unicode-range` itself remains unmodelled (this fix removes the serialization cost of the collision, not the collision — all five rules still compete for one slot, and whichever succeeds first wins for the WHOLE family+weight regardless of which glyphs it actually covers; a page relying on Font Awesome's REAL icon-subset behavior could still render the wrong glyphs, just not slowly). `cs.cmu.edu` itself could not be cleanly re-measured after this fix landed — the live-site contamination described above persisted (still ~45s on a careful single re-check well after the fix merged), consistent with the origin's own throttling outlasting this session rather than the fix being ineffective (the deterministic local test is the real evidence it works). Checked ONE other slow page from the same bench run, `foundation.zurb.com` (24.8s in the run, not yet touched by any of this round's live testing, so uncontaminated): still ~40s after the fix, and — checked directly rather than assumed — `DisableJS=true` dropped it to ~6.2s on the SAME page, meaning its slowness is JS-settle-related, NOT the font-face bug this round fixed. **Correcting the round's own earlier guess**: `cs.cmu.edu`'s shape is not a shared cause across the other ~9 slow pages; at least `foundation.zurb.com` has a distinct, unrelated, JS-driven cause, still open for a future round.
 
 ## 2026-10-09 (round 167) — the interrupted 500-page bench run (round 166's own queued work) found a second real crash: a lone CSS Grid item using `grid-row:1 / -1` with no explicit row template panicked on an empty row-offset slice (engine#266, patch)