perf (evaluate): EPUB assembly does a per-page Buffer→string→Buffer round trip and emits 3 tiny zip chunks per entry

[JavaGT]

Filed by the Account-2 read-only amplifier (2026-09-16, HEAD f635e62). Problem (CPU hot path, coordinator-verified):

• Pages double-convert: pageBodyOf returns d.toString('utf8') (src/epub.mjs:251-255), wrapPage composes strings (src/epub.mjs:296-299 thunk), then resolveData re-encodes with Buffer.from(d,'utf8') when the payload isn't already a Buffer (src/epub.mjs:33-37) before deflate — one full decode+re-encode per page per assembly.
• zipChunks yields 3 chunks per entry — 30-byte local header, name, payload (src/epub.mjs:154-158) — so a book pushes hundreds of micro-writes through the pipeline; header+name could share one combined alloc.
• zipChunks also re-implements layout()'s offset/dirSize accounting inline (src/epub.mjs:151-153 vs :49-58) — mirrored accounting, drift currently mitigated only by the byte-identity test (test/epub-integrity.test.mjs:131).

Evaluation question (implementation is NOT the todo until measured): buffer-concat wrapping + combined header/name alloc, measured in the bench zip_assembly section — the one harness that exists for this path. Byte-identity tests must stay green. Note: zip_assembly outputBytesAgree:false vs perf/baseline is expected from the intentional rewrite — compare current-vs-candidate, not vs baseline. Deflate level should get a pin regardless (tracked under #19).

Proposed focus packet: wrapPage on Buffers (viewport insert as buffer concat), single header+name alloc in zipChunks, shared accounting helper, bench A/B + epub-integrity green.

[JavaGT]

Measured evidence from the Account-2 read-only amplifier (2026-09-20, HEAD ce11aca — i.e. after the #33/#34 landings this issue predates; coordinator-only pass, no child workers; evidence = read + inline node --input-type=module -e measurement, Node v26.7.0, Apple M4 — the only file inputs are committed fixtures, nothing written, no caches; git parity re-verified after).

Claim chains re-verified at HEAD — both still hold:

• Pages: staging thunk () => fs.readFileSync(dest) (src/archive-read.mjs:127) → pageBodyOf decodes d.toString('utf8') (src/epub.mjs:253) → wrapPage composes a string → resolveData re-encodes Buffer.from(d, 'utf8') (src/epub.mjs:35) → deflate. One full decode + re-encode per page, live.
• zipChunks still yields 3 chunks/entry — 30-byte header, name, payload (src/epub.mjs:154-158).

Measured:

• Double conversion per page (decode + re-encode medians): 0.001 ms @ 3 KB, 0.003 ms @ 20 KB, 0.034 ms @ 256 KB.
• Whole 129-page book (real spine size from the committed fixture sample-data/magazine-13554110/openbook.json): 0.088 ms (3 KB pages) … 0.337 ms (20 KB pages).
• Whole buildEpub assembly CPU (129 pages × 3 KB + 129 × 200 KB stored assets): 4.1 ms.
• Context: assembly CPU is single-digit ms against a wall dominated by hundreds of page/asset RTTs (the perf (evaluate): readable path fetches every page before the first asset RTT — overlap the two mapLimit phases #22/perf: readable staging writes are sync inside the mapLimit pools and pages re-mkdir per page — event-loop stalls between RTTs #34 world).

Lean (measurement conclusion, not an approval): measured decline for the per-page round-trip claim — the entire assembly is ~4 ms, so removing the double conversion cannot buy a perceptible millisecond. The zipChunks-re-implements-layout duplication sub-claim stands as a refactor nit (fold into any future epub.mjs work); the 3-chunks-per-entry sub-claim is stream-backpressure noise at these sizes. Decision question unchanged: evaluate, not implement.