TAR preview evidence

App revisions:
base 9db3cb10916c81830efa0d0d7be6601d2fe51158
head 8c492c457a186f61aeab3ad1c9c07799f65ff45f

Environment: Linux x86_64, Google Chrome 151.0.7922.108, headless,
1440x900 viewport, dark theme. Both apps were dev servers from separate
checkouts on the same machine, with independent fresh T3 homes and
T3CODE_DEV_SEED=0. Only synthetic project files and replay-agent history.
The Vite dependency caches were warm before the final series.

Reproduce:
1. Install dependencies with vp i in each checkout.
2. python3 seed.py <fixture-directory>
3. In each checkout start the real dev app (keep it in a terminal):
   T3CODE_DEV_SEED=0 node scripts/scenarios/start-app.ts web <side-home> 127.0.0.1 <port>
   Use root/base-home and port 18734 for base; root/head-home and port 18733 for head.
   Wait for the app to listen and for side-home/pairing-path to exist.
4. In each checkout seed the project and a free replay turn using its CLI:
   node apps/server/src/bin.ts project add <fixture-directory> --title 'Archive evidence' --base-dir <side-home>
   node apps/server/src/bin.ts thread start <fixture-directory> go --title 'Archive preview' --provider devReplay --model showcase --base-dir <side-home> --json
   Keep the returned threadId for that side.
5. Run measure.mjs with Node, in sequence (no simultaneous measurements):
   node measure.mjs <base-checkout> <root> base 18734 <base-threadId> mixed.tar 5
   node measure.mjs <head-checkout> <root> head 18733 <head-threadId> mixed.tar 5
   node measure.mjs <base-checkout> <root> base 18734 <base-threadId> control.tar 5
   node measure.mjs <head-checkout> <root> head 18733 <head-threadId> control.tar 5
   The script resolves playwright-core from the checkout's scripts package.
6. python3 summarize.py <root> produces summary.json and comparison.png.

For every sample the driver launches a new Chrome process, pairs, opens the
seeded thread by URL, opens right panel > Files, and clicks the archive.
An observer wraps the browser's Worker.postMessage and message listener to
measure open-request-to-archive-reply latency. The worker code is unchanged.
This timing excludes fetching the archive and excludes React rendering.
The control archive is only a retained-memory baseline; its small fetch can
finish before the worker imports, so its timings are not a speed comparison
with mixed.tar.

Once the listing is present, the driver attaches CDP to binaryPreview.worker,
collects garbage three times and records Runtime.getHeapUsage. It clicks
large.txt, checks the existing 10 MB limit error (or 'a' for the control),
returns to the listing and opens after.txt, checks 'after', then collects
three more times and records memory again. The raw JSON includes both heap
samples, every listing, every entry's size and every latency.

The first run of each series is recorded. Stills require two byte-identical
screenshots 500 ms apart. The file explorer is hidden for captures to make
all archive names readable. Published mixed.tar videos omit startup and
pairing: before.mp4 begins at 11.4 seconds of its original recording;
after.mp4 begins at 8 seconds. The complete archive interaction remains.

Measurements show retained backing storage, not a separate transient
allocation profile. No end-to-end user-perceived latency claim is made.