Message ordinal index: real-server proof driver

Commits:
  base f7b0b3c4d730fbf40b87465523631a7d3ac33472
  head 37228e3f4cc86f6e9f0a742e333c52158ed28ea9

Requirements: Linux x86_64, repository dependencies installed with vp i,
Node v26.13.1 (SQLite 3.54.1), Python 3; Pillow for rendering captures.

1. In each isolated checkout, run T3CODE_DEV_SEED=0 vp run dev.
2. Create an empty git workspace. In each checkout, use the real CLI:
   node apps/server/src/bin.ts project add --base-dir .t3 WORKSPACE
   node apps/server/src/bin.ts thread start --base-dir .t3 --provider devReplay --model multi-turn --json WORKSPACE go
3. Seed each returned thread using seed.py CHECKOUT THREAD --count 1200 --out NEW_DIRECTORY.
   This uses six CLI sender processes. The measured run had one base-side sender
   interruption; after counting 902 persisted runs (including the initial turn),
   mcp-driver.mjs CHECKOUT THREAD NEW_DIRECTORY seed 299 supplied the remainder.
   All messages use the same synthetic payload; the input schema trims whitespace.
4. Run:
   python3 benchmark.py BASE_CHECKOUT HEAD_CHECKOUT BASE_THREAD HEAD_THREAD NEW_OUTPUT_DIRECTORY
   The script waits until each database contains exactly 1201 completed runs and
   no queued or running turns. It reads the complete history through the server,
   compares canonical position/type/text SHA-256, then runs 11 alternating batches
   per side with five warmups and 21 measured requests per batch.
5. The measured action is the real server MCP tool t3_thread_read with view=messages,
   limit=100, runLimit=1, maxCharsPerItem=20000. It returns the first message page (22 messages in this run),
   while its ordinal statement groups the complete thread's message items.
   Request timing uses performance.now around the tool call on a persistent
   connection. SQL timing is the actual sqlite span in server.trace.ndjson,
   selected by the request timestamps and the ordinal query text. Every batch
   must contain exactly 26 matching SQL spans before discarding warmups.
6. plans.mjs runs EXPLAIN QUERY PLAN on the actual application-created database,
   using the corresponding commit's full and bounded-100 ordinal statements.
   It records ordinal results as well as both plans. Within each database, both
   result forms must match the original query forced through the thread/type index
   (including exact message IDs and ordinals). It does not seed or mutate data.
   Internal run ordinals differ across independently queued fresh databases; the
   app-visible position/type/text histories are compared across commits instead.
7. Run python3 capture.py OUTPUT_DIRECTORY. It checks each measured response
   against the complete history and renders each side's numerical output to TXT/PNG.

No test suite, inserted projection rows, copied real database, modified replay
agent, or standalone SQL benchmark provides the performance measurement.
Plan inspection is supplementary to the actual server trace timings.

Metrics: the central estimate is the median of 11 per-batch medians, with the
minimum/maximum of those medians exposing between-batch spread. Individual
samples, including outliers, are retained in batches.json and summary.json.
The first five calls in every batch are excluded consistently on both sides.

The synthetic history and timing samples in evidence-data.zip are public;
credentials, server origins, workspace locations, and full server logs are excluded.
