Production findings for a od-base round (route a): admission budget vs the 297 s window #28

Found while preparing a real od-base round on the test challenge (joinbase-6, 2026-10-21). Nothing fixed here. Related: #25 (host field / generic promotion), PR #27 (production bootstrap).

1. A 40-trial round is impossible with the default admission policy. Each next trial must finish before seed+100 with seed = finalize+1 (admission.py:200, 255, 893), so trials run back-to-back. Eligibility lasts work_screen_epoch_rounds (default 1000, from ops/manifest_v2.py:187) after the last proof (admission.py:751, 940), with at most 2 open trials (max_trial_replays: Literal[2]). 3 active miners cannot all stay eligible until a round finalizes. The test run used work_screen_epoch_rounds=6000 as a declared deviation. The production manifest or the admission code must change.
2. The 297 s window is spent mostly by the service. Per trial, under the store lock: export staging (init_params + genesis + 7.2 GB of dataset objects reloaded each time, ~9 s on a fast host, ~20 s on an ordinary 5090 host, 58 s+ on a loaded box), then the reference run (63-131 s) with staging again. On a fast host about 180 s with ~100 s margin; on an ordinary 5090 host it exceeds 297 s. An external miner on an ordinary host cannot meet the window.
3. The beacon pusher cannot fill gaps. A lock-heavy operation can leave permanent holes in the beacon rounds.
4. Bench before admission. One missed trial loses the coldkey permanently (admission.py:222-228, CHALLENGE_EXPIRED). Miner docs should require a bench (probe <= ~150 s) before join.

Evidence: livrables/forge/2026-10-21_deploy-hypertrain-joinbase-6.md section 5 (Cortex shared deliverables).