Phase 3c: fix production vr_sync abort; full game runs through renderer

Root cause: vpx_max_postboot_acks=200, a Phase-2 bring-up guard, capped how
many post-boot replies the device would ever feed. A real BattleTech session
issues an unbounded stream of sync/frame/render replies and aborted with
"velocirender_receive timed out - sends_wo_rcv" at exactly the 200th ack
(143 sync + 55 frame-ack + 2 render). Cap is now effectively unlimited
(0x7fffffff; override VPX_MAX_ACKS for diagnostics).

After the fix the full game (game.conf, RIO disabled, cycles=max) runs
indefinitely: 2500+ syncs, 1264+ frame-acks, no abort, into L4VIDEO content
load (Thor mech + terrain from ALPHA_1/REL410/BT/VIDEO/GEO -- 841 real .bgf
models; test.egg is only mission params). Window still shows background:
the game uses the full DPL hierarchy (instance/object/lod/geogroup + DCS
transforms) which the flat flyk-tuned scene walk doesn't traverse yet -- that
is Phase 3d, documented in PHASE3-PROGRESS.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

emulator/PHASE3-PROGRESS.md

@@ -1,10 +1,14 @@
 # Phase 3 — Render Backend: Progress
 
-**Status (2026-07-03): Phase 3a + 3b complete. 3a — the render command stream
-is fully captured and decoded, and a captured DIVRGB frame reconstructed to
-pixels offline. 3b — a live OpenGL window built into the emulated board draws
-each frame in real time inside DOSBox-X. First images ever produced from the
-Rel 4.10 VPX protocol without a real board.**
+**Status (2026-07-03): Phase 3a + 3b + 3c complete. 3a — the render command
+stream is fully captured and decoded, and a captured DIVRGB frame
+reconstructed to pixels offline. 3b — a live OpenGL window built into the
+emulated board draws each frame in real time inside DOSBox-X. 3c — the
+production `vr_sync` abort is fixed and the full BattleTech v4.10 game now runs
+indefinitely through the emulated board, drawing 1000s of frames (was hard-
+capped at 200). First images ever produced from the Rel 4.10 VPX protocol
+without a real board. Next (3d): traverse the game's DPL hierarchy + DCS
+transforms so its mechs actually appear.**
 
 ![decoded DIVRGB calibration screen](divrgb-decoded.png)
 
@@ -108,14 +112,57 @@ before its first receive, which the POLL_THRESHOLD gating stalls. This is not
 a 3b issue (the `flyk` clean-launch path renders fine); it is the same
 production-sync item still open from Phase 2.
 
-## Remaining
+## 3c. The full game runs through the live renderer (sync abort fixed)
 
-1. **Production-path vr_sync timeout** (`sends_wo_rcv`): the game's
-   `btdpl.ini`/netnub launch path. Needed before the game itself renders.
-2. **Content**: `test.egg` carries no models, so even past sync the game has
-   no `buttee.bgf`/`mslr.bgf` geometry to draw — needs a real mission/content
-   tree from the pod image.
-3. **DOS/4GW sync variant** for the CYCLE `flyk yip.scn` fixture (Red Planet
+**The production `vr_sync` abort is fixed, and BattleTech v4.10 now runs
+indefinitely through the emulated board + live renderer.** Root cause was a
+Phase-2 bring-up guard left in the device: `vpx_max_postboot_acks = 200`
+capped how many post-boot replies the device would ever feed. A real game
+session issues an unbounded stream of sync/frame/render replies; the game
+aborted with `velocirender_receive timed out — sends_wo_rcv` the instant the
+device fell silent — at *exactly* the 200th ack (measured: 143 sync + 55
+frame-ack + 2 render = 200). The cap is now effectively unlimited
+(`0x7fffffff`, override with `VPX_MAX_ACKS`). Same run after the fix: 2500+
+syncs, 1264+ frame-acks, no abort. The game progresses past sync into
+`L4VIDEO.cpp` content/entity setup (loading the Thor mech and terrain) and
+draws continuously.
+
+Contrary to the earlier note, the content **is** on the production image: 841
+`.bgf` models under `ALPHA_1/REL410/BT/VIDEO/GEO` (incl. `BUTTEE.BGF`,
+`MSLR.BGF`, the `THR*` Thor mech). `test.egg` is only mission parameters (as
+the pod owner said); the geometry loads from `VIDEO/GEO` regardless.
+
+Game render config: `game.conf` (RIO disabled so the missing cockpit board
+doesn't stall the control manager; `cycles=max`).
+
+### What the game's wire stream looks like (vs. flyk)
+
+The game geometry path is heavier and different from flyk's flat DIVRGB:
+- **action 26 (0x1A) dominates** — texture texel upload. 32-byte headers
+  `[node][size][w][h]` (`0x1000`=64×64, `0x4000`=128×128 tiles) then 256-byte
+  texel rows. 2880+ of these = the mission texture set streaming in.
+- action 28 (0x1C): material/light parameter blocks.
+- actions 23/25 (verts/conns) still carry mesh geometry but are a small
+  fraction of the stream.
+- The scene graph is the **full DPL hierarchy** — zone → dcs → instance →
+  object → lod → geogroup → geometry — with **DCS transform matrices**
+  positioning each mech/prop. flyk's DIVRGB put geometry directly in
+  geogroups at world coordinates.
+
+## Remaining (Phase 3d: game geometry on screen)
+
+The window currently shows only the view background for the game because the
+live backend's `scene_publish_frame()` walks the *flat* flyk layout
+(geogroup→geometry at world coords). To draw the game's mechs it must:
+
+1. **Traverse the full hierarchy** (instance/object/lod/geogroup) and **apply
+   DCS transform matrices** (accumulate the 4×4s down the graph) so each mech
+   lands at its world position; pick a LOD.
+2. **Arena content search path**: the game logs `couldn't load object
+   thr_tshd.bgf` — that object lives in `VIDEO/GEO/ARENA/` and `…/POLAR/`
+   (arena-specific), not the top `GEO` dir; the geometry search path needs the
+   selected arena subdir (a `setenv`/config detail, not protocol).
+3. **Texturing** (action 26 texel maps + SVT), lighting, depth/material.
+   Current backend is flat-shaded untextured polys.
+4. **DOS/4GW sync variant** for the CYCLE `flyk yip.scn` fixture (Red Planet
    geometry) — the older action-check sync.
-4. Texturing (`set_texmap_texels`, action 23-data + SVT), lighting, and
-   depth/material niceties; current backend is flat-shaded untextured polys.