perf (speculative): three micro-candidates (round 3) — evaluate each before any work

[JavaGT]

Filed by the Account-2 read-only amplifier (2026-09-19, HEAD 246b710; coordinator + read-only static pass; evidence = read + rg + one non-mutating inline node -e measurement over the committed fixture sample-data/_sync.json — no script, file, or checkout state was created or changed). Three low-stakes candidates from the not-yet-reviewed auth/bootstrap + auth-free-discovery + sentry-transport surface (round 3, after #28 and #36). Each is evaluate whether it is worth doing — implementation is explicitly NOT the todo. Overlap-checked against all 37 open+closed issues; none of these symbols/claims is ticketed elsewhere.

1. SentryClient.request eagerly utf8-decodes + JSON.parse-attempts every body and retains text + buffer simultaneously — src/sentry.mjs:96-108. Same class as landed perf T3-W1: collect() utf8-decodes + JSON.parse-attempts every binary body (covers, page assets) — make text/json lazy #4 (http.mjs collect laziness) and perf (speculative): five micro-candidates (round 2) — evaluate each before any work #36.4 (collect 2× residency), but a distinct, unticketed surface: the auth/sync/gateway client every authed invocation travels through. On the committed real-world /chip/sync fixture (sample-data/_sync.json, 223,193 bytes), measured inline on this machine (Node v26.7.0, Apple M4): eager decode+parse ≈ 0.31 ms CPU per invocation, and the response path peaks at chunks + concat buffer + utf8 string ≈ 3× body (~0.7 MB transient per invocation) while requestOk callers (e.g. loans.sync, src/loans.mjs:13) consume .json only. Distinct from chore: four confirmed dead/redundant surfaces — un-export jsonRequest, drop dead sanitize import, drop double chmod, drop dead raw option #26.4 (dead raw option — different claim, same function). Evaluate: mirror collect's lazy text/json getters and drop unread retention. ms-scale / peak-memory only; decline freely.

2. Fresh bootstrap serializes resolveILS behind mintChip, though resolveILS depends only on config — src/auth.mjs:86-87 (mintChip → linkCard) with the forms GET inside linkCard (src/auth.mjs:122, :134: GET /auth/forms/{websiteId}, no identity needed). Hiding one READ_HOST RTT (~70–500 ms by the campaign's own accounting, perf (speculative): evaluate dropping return's unconditional loan sync — one warm /chip/sync RTT (~70-500ms) spent purely on output fidelity #16/perf: list/archive/return fetch /chip/sync twice per invocation — authenticate's verify already holds the payload (~568 ms measured) #17) would speed libby init's verify and every forced re-bootstrap (dead-session recovery, bin/libby.mjs:578; also each retry loop of POST /auth/link returns 401 credentials_rejected for at least one library (Mid-Continent Public Library, websiteId 339) despite valid credentials #1's credentials_rejected debugging). The non-trivial part — and why this is evaluate-only: SentryClient deliberately pins maxSockets: 1 (src/sentry.mjs:55-59, "the browser's chip binding is happier that way"), so a true overlap needs a second socket/agent for the pre-auth forms GET, which touches that constraint. Speculative: the fresh path runs once per token expiry, not per invocation.

3. getAvailability fetches >100-id lists in strictly serial chunks — src/discover.mjs:31-37: ids chunked at 100 (Thunder cap) and awaited in a serial loop, so n ids pay ⌈n/100⌉ back-to-back RTTs; the pool primitive already exists (src/pool.mjs mapLimit). Reachable from the CLI (libby avail takes an unbounded id list, bin/libby.mjs:337-344) and as a public API export (src/index.mjs:30). Speculative: realistic CLI use is well under 100 ids; only worth it if a batch use case materializes.

Decision question (evaluate, not implement): for each candidate, is it worth doing at all? Expected terse letter-grade answers (adopt/adapt/decline) with reasons; 1 is the strongest (consistency with the already-optimized collect), 2 and 3 are likely declines until a real workload appears.