Confirmed scene loading: operation-budget investigation

Evidence from the user's Detail Playtest 3 runtime.log, 22 October 2026:

- The native-menu and owned-menu diagnostics appear for two available car
  pickers. The preceding repair is active; no menu drawing fault is logged.
- The actual failure is during confirmed scene resumption at site 6, after
  CPU car and character selection. Six racers are being constructed.
- The operation counter is exactly 40,000,001. The stack is init_track ->
  track_setup_racers -> spawn_object -> obj_init_attachpoint ->
  obj_spawn_attachment -> tex_load_sprite -> load_texture -> mempool_alloc
  -> mempool_slot_find. There is no invalid guest address in the failure.
- Successful individual background preview loads earlier in the same log
  used 9,383,536 to 11,129,096 operations. Full race construction must load
  multiple racers and their attachments, not just one background preview.

Source findings:

The final private driver gives the entire confirmed scene continuation a
literal 40,000,000 operations, the same order of allowance as a menu tick.
All nested reviewed guest callbacks consume that same root allowance. The
new all-player residency policy admits the highest racer LODs on all peers,
so construction can do more legitimate loading than the old split-screen
lower-LOD path. The log alone does not establish the exact completed cost.

The private generated allocator already validates the pool/index via the
memory service and rejects a walk after dkr_find_max visits. The decomp's
best-fit search walks the slot list for each allocation. It has a 1600-slot
main pool and 20-byte entries. These guards and this algorithm are retained;
an operation-budget stop is not itself evidence of RAM corruption.

Scoped repair:

Only build-local copies of the two final private probe_driver.cpp files are
changed. The already-authorized, GPU-drained confirmed scene continuation
gets a finite 256,000,000-operation allowance. Background loading retains
40,000,000; running-race work retains 5,000,000. No retry grants another
allowance, no exception is swallowed, and no allocator/memory check is removed.
Both peers get a path-independent hashed policy contract. Cost diagnostics
are emitted once per load, including a failed load, not once per render frame.

The new allowance is deliberate headroom, not a measured claim that every
possible mod set completes within it. Owner gameplay confirmation is required.
No game, mod, test executable or AppImage is executed during this workflow.
