perf (evaluate): no journey instrument for return, hold, unhold — interactive-surface perf rests on code-level RTT accounting

[JavaGT]

Filed by the Account-2 read-only amplifier (2026-09-16, HEAD f635e62). Problem: measured harnesses exist only for the archive audio+read paths (perf/archive-parallel-sim.mjs:1-20,297) and startup/help (perf/bench.mjs:164-181); perf/net-sim.mjs:32-68 exercises raw http/pool primitives, not command journeys. borrow/auth/search/avail/info were measured by one-off live A/B probes recorded in perf/lanes/T6-W1-report.md:39-76 — uncommitted, not re-runnable. return/hold/unhold have no instrument at all (dispatch-only evidence, bin/libby.mjs:478-511).

Why it matters: the 2026-09-16 0330 no-finding audit over the interactive journeys is code-level RTT accounting, and its own hostile review flagged exactly this (F2, artifacts/automation-receipts/2026-09-16/review-0330-nofinding-2.out). Concretely, #16's evaluation is blocked on a hermetic return journey: the overdrive sim lacks the chip/auth surface (deferred per perf/lanes/T6-W1-report.md:81-84), sim-sentry-stub.mjs:53-56 logs method/path with no timing and responds instantly, and no warm-vs-cold /chip/sync RTT distribution exists (net-sim is generic GETs with a loopback caveat, perf/net-sim.mjs:8-9).

Evaluation question (implementation is NOT the todo): build the hermetic journey harness — latency-injected chip surface in the sim, warm/cold RTT distribution capture, output-parity snapshot so fidelity changes are visible — or explicitly decline per surface with reasons.

Proposed focus packet: extend test/helpers/overdrive-sim.mjs with a timing-configurable /chip/sync; add a journey runner that drives bin/libby.mjs subcommands end-to-end; first customer is #16's warm return --yes A/B. Cross-refs: #16, #19.

[JavaGT]

Account-2 read-only amplifier, artifact-coverage audit (2026-09-18, HEAD 246b710) — three additions to this ticket's instrument-gap inventory, found by re-reading every committed measurement artifact (no new measurements run):

1. The T7-W1 list/auth A/B exists only as prose. The perf: list/archive/return fetch /chip/sync twice per invocation — authenticate's verify already holds the payload (~568 ms measured) #17 numbers (list 2676.2 → 2121.5 ms, −554.7; list−auth 783.9 → 162.4) live in perf/lanes/T7-W1-report.md — no JSON artifact anywhere records them (rg over all committed *.json finds no 2676/2121 fields). Same un-re-runnable class as the T6-W1 probes this ticket already names.
2. perf: list/archive/return fetch /chip/sync twice per invocation — authenticate's verify already holds the payload (~568 ms measured) #17's reconciled "27.1 ms marginal over auth" is unrecomputable — the auth median it is a delta over is stated in no artifact (review-0330-round2.out:55 is prose too). A future journey harness should re-baseline this number or retire it.
3. borrow's measured A/B covered only the failure path. T6-W1-report.md:39-56 used a fake title id → the periods GET 400s in both trees; the borrow POST is never reached. The borrow happy path has never been measured end-to-end. search/avail/info "900–2450 ms" (T6-W1-report.md:66) is also prose-only.

No new ask — these widen the coverage inventory this ticket's evaluation question already covers (hermetic journey harness vs explicit per-surface decline). The first customer remains #16's warm return --yes A/B; borrow-happy-path and list/auth re-measurement are additional candidates for the same harness.