docs(runtime): record J0 and physical I6 evidence

Pin the exact J0 rollback, synchronize the roadmap and agent handoff files, and distinguish the observer-heavy two-gigabyte soak from the ordinary-client physical sample. Keep parsed collision graph removal explicitly behind the pending user collision and visual gate.

Co-authored-by: Codex <codex@openai.com>

docs/research/2026-07-25-slice-i6-flat-production-cutover.md

@@ -90,6 +90,49 @@ Stable result:
 The parsed graph is still resident in those memory figures. I6 graph removal
 must reduce that footprint and prove stable production graph counts are zero.
 
+## Physical-display full-route soak
+
+An exact clean worktree at source/binary `9f37d1793674a7bf5101ef22d5c5d956b8d101a2`
+completed the canonical nine-stop route on the physical display:
+
+- all nine checkpoints and every materialization passed;
+- Caul, Holtburg, and return-to-Caul movement/jump/combat exercises passed;
+- server-spawned/static lifecycle checks passed;
+- final publication, retirement, worker, destination, control, unload,
+  near/far, staged-upload, and composite-warmup backlogs were all zero;
+- graph and flat residency agreed at 175 cells in the final stable state;
+- graph retention remained intentional for the pending user gate;
+- diagnostic-route memory plateaued at 2.020 GiB in Sawato and 2.061 GiB on
+  final Caul rather than growing without bound;
+- instrumented-route GPU p95 stayed at or below 2.8 ms.
+
+The roughly 2 GiB diagnostic working set is not the ordinary client footprint:
+that route deliberately retains the old and new collision representations and
+enables the full current-path render oracle.
+
+A separate ordinary uncapped Release client at Caul with about 21,025 live
+entities, no profiler, no render oracle, and no route automation produced this
+20-sample physical-display result:
+
+- 156 FPS average (140 minimum, 166 p95, 172 maximum);
+- 6.42 ms average displayed frame time;
+- 7.50% average whole-machine CPU;
+- 27.07% average GPU 3D utilization;
+- 1.080 GiB average working set;
+- 1.291 GiB average private bytes.
+
+The uncapped GPU percentage is demand created by rendering as fast as the CPU
+can submit frames, not evidence of a GPU bottleneck: measured GPU frame p95
+remained below 3 ms while displayed frame time was about 6.4 ms. Memory remains
+above the target while both collision representations are intentionally
+resident; the accepted graph-removal step must measure the reduction.
+
+A later 20-sample repeat from the same still-connected process confirmed the
+plateau: working set stayed exactly 1.059 GiB and private bytes exactly
+1.236 GiB throughout the sample. It averaged 177.6 FPS / 5.65 ms, 7.67%
+whole-machine CPU, and 30.40% GPU 3D. The higher GPU percentage tracked the
+higher uncapped frame rate; it did not coincide with working-set growth.
+
 ## Acceptance boundary
 
 The automated cutover gate is complete. Before deleting the referee and parsed