perf (evaluate): freeze/gate the deflate level choice — deflate_levels is informational, a level drift lands silently

[JavaGT]

Filed by the 2026-09-17 0330 automation run. Source: hostile review round 1 of #19 (finding F5, LOW). Problem: bench section deflate_levels records level-9 vs level-6 time/ratio tradeoffs but nothing pins the chosen level (epub assembly's level 6) — a code change to the level, or a zlib behavior shift, would land silently. Evaluate whether this is worth doing — implementation is explicitly NOT the todo: e.g. a node --test pin asserting epub.mjs uses level 6, or gating a deflate ratio floor in the bench gate; weigh against the section's role as a decision instrument rather than a budget.

[JavaGT]

Measured evidence from the Account-2 read-only amplifier (2026-09-20, HEAD ce11aca; coordinator-only pass, no child workers; inline node --input-type=module -e over committed fixtures, Node v26.7.0, Apple M4; nothing written, git parity re-verified after).

The encodeEntry comment's claim ("level 6 over 9: ~2x faster, within ~2% on text", src/epub.mjs:44-45) reproduces independently:

payload (real where noted)	raw B	L6	L9	L6 vs L9
openbook re-stringified (real OverDrive payload)	103,001	0.37 ms / 15.4%	0.71 ms / 15.2%	1.9× faster, +0.2 pp
README prose (real)	11,197	0.08 ms / 42.2%	0.10 ms / 42.2%	1.3× faster, +0.0 pp
synthetic 20 KB xhtml	20,000	0.03 ms / 1.0%	0.03 ms / 1.0%	parity (per-call overhead dominates)

Book-scale from measured rates: ~3.6 ms/MB of page text at L6 — a realistic book's page text (0.4–2.6 MB) costs single-digit ms at L6, so even a silent drift to L9 costs only ~2× single-digit ms per book. Side observation, not a recommendation: L1/L3 measure ~2× faster again at +1.3 pp ratio on the 103 KB payload.

Factual base for the evaluate question: deflate level is a single-digit-ms-per-book knob; a drift changes bytes and a few ms, not user-visible wall time. A pin (node --test asserting level 6, or a ratio floor in the gate) is therefore cheap byte-stability insurance, nothing more — adopt only if byte-stable output matters to the owner; decline freely otherwise. Decision question unchanged: evaluate, not implement.