perf (speculative): five micro-candidates (round 2) — evaluate each before any work

[JavaGT]

Filed by the Account-2 read-only amplifier (2026-09-18, HEAD 246b710; coordinator + 3 read-only workers; static evidence only — no benchmark or script was run, per the read-only contract). Five low-stakes candidates from the audio/read data-plane sweep (round 2, after #28). Each is evaluate whether it is worth doing — implementation is explicitly NOT the todo. All evidence coordinator-verified (read + rg).

1. Sidecar writeJson trio sits on the critical path before the download pool starts — openbook.json / openbook-extra.json / loan.json are stringify+writeFileSync at src/archive.mjs:81,84,91, all before mapLimit at :98. Kicking the pool first (or async sidecar writes) hides stringify/write CPU under network wait. ms-scale, grows with TOC size. Evaluate: check real openbook.json sizes in collected payloads before bothering.
2. Double stat on the resume check — archive.mjs:101 does existsSync(dest) ? statSync(dest).size : 0 — two syscalls where one try { statSync } suffices. Nano; fold into any other archive.mjs edit or decline.
3. Cover is fully buffered in memory — metadata.mjs:58-63 downloadCover uses fetchBuffer (entire max-res image resident) then sync writeFileSync, vs streaming to disk the way downloadPart does. Peak-memory-only (MBs), not wall time. Evaluate: are multi-MB covers common?
4. collect() transient 2× residency per body — http.mjs:50-53 pushes chunks then Buffer.concat, so chunks + result coexist: per-body peak ≈ 2×. A Content-Length-preallocated buffer filled in place halves it (fall back to concat when no CL). Speculative: is peak RSS during the 4-way asset phase a real constraint on multi-MB magazine scans? Distinct from perf T3-W1: collect() utf8-decodes + JSON.parse-attempts every binary body (covers, page assets) — make text/json lazy #4 (laziness, landed) and perf (speculative): six micro-candidates — evaluate each before any work #28.3 (sentinel).
5. Per-asset base rewrite — archive-read.mjs:140 re-runs web.replace(/\/$/,'') per asset; extractSpine already computes the identical base (openbook.mjs:320). Nano; only worth a one-liner if perf (evaluate): readable path fetches every page before the first asset RTT — overlap the two mapLimit phases #22's rework touches this code anyway.

[JavaGT]

Measured evidence for item 1 (sidecar writeJson trio) from the Account-2 read-only amplifier (2026-09-20, HEAD ce11aca, post-#34; coordinator-only pass; inline node --input-type=module -e over committed fixtures, Node v26.7.0, Apple M4; nothing written, git parity re-verified after).

Claim chain still holds at HEAD: openbook.json / openbook-extra.json stringify+write at src/archive.mjs:83-91 and loan.json at :96 all precede the mapLimit pool at :105; writeJson = JSON.stringify(data, null, 2) + writeFileAtomic (src/util.mjs:104-107).

Real payload sizes from the committed magazine fixture (sample-data/magazine-13554110/): openbook.json 154,702 B, openbook-extra.json 1,351 B, loan.json 3,852 B.

Measured (stringify(null,2) + one write()): 0.221 + 0.006, 0.001 + 0.006, 0.004 + 0.007 ms → trio total ≈ 0.25 ms, and that's a lower bound (writeJson actually pays tmp-write + rename).

Against the campaign's own RTT accounting (70–500 ms per /chip/sync- or READ_HOST-class RTT): hiding 0.25 ms behind the pool buys < 0.4% of one RTT.

Lean (measurement conclusion, not an approval): measured decline — kick-the-pool-first would reorder the open path to hide a quarter millisecond. This resolves item 1's own gating question ("check real openbook.json sizes before bothering": done — 154 KB, and the CPU is negligible at that size). Items 2–5 untouched. Decision question unchanged: evaluate, not implement.