# Control-Loop Atlas

This atlas is the high-level map for RT3 1.06. It is intentionally broader than the function map:
each section explains who owns a loop, where it starts, what dispatches it, which state blocks
anchor it, and where control is handed to neighboring subsystems.

Subsystem notes now live under [docs/atlas](/home/jan/projects/rrt/docs/atlas/README.md) for
faster navigation. The longform atlas remains the canonical narrative reference during this
transition.

## CRT and Process Startup

- Roots: `entry` at `0x005a313b`, CRT helpers in the `0x005a2d..0x005ad4..` range, and
  `app_bootstrap_main` at `0x00484440`.
- Trigger/Cadence: single process startup path before shell or engine services exist.
- Key Dispatchers: `startup_init_tls_state`, `startup_init_file_handle_table`,
  `startup_run_init_callback_table`, `__setenvp`, `startup_build_argv`,
  `___crtGetEnvironmentStringsA`, then `app_bootstrap_main`.
- State Anchors: CRT heap and file-handle tables; process environment and argv storage.
- Subsystem Handoffs: exits the generic CRT path at `app_bootstrap_main`, which becomes the first
  RT3-owned coordinator.
- Evidence: `artifacts/exports/rt3-1.06/startup-call-chain.md`,
  `artifacts/exports/rt3-1.06/function-map.csv`.
- Open Questions: exact ownership boundary between compiler CRT shims and the first game-owned
  bootstrap helper; whether any nontrivial startup callbacks seed game globals before
  `app_bootstrap_main`.

## Bootstrap and Shell Service Bring-Up

- Roots: `app_bootstrap_main` at `0x00484440`, `bootstrap_init_shell_window_services` at
  `0x004840e0`, and `shell_install_global_controller` at `0x0051ff90`.
- Trigger/Cadence: one-time bootstrap handoff immediately after CRT completion.
- Key Dispatchers: `app_bootstrap_main`, `bootstrap_init_shell_window_services`,
  `shell_install_global_controller`, `shell_service_pump_iteration`, graphics config load or
  default-init helpers, runtime capability probes, and early shell service initializers under the
  `0x004610..0x0053f0..` branch.
- State Anchors: global shell controller pointer `0x006d4024`, sibling display/runtime globals under
  `0x006d402c` and `0x006d4030`, and host capability flags gathered by
  `bootstrap_probe_system_profile`.
- Subsystem Handoffs: after the global shell controller has been installed the bootstrap path enters
  the repeating `shell_service_pump_iteration` loop, which services shell-state work and hands each
  iteration down into the controller frame path; when the shell lifetime ends this same bootstrap
  path tears the shell bundle down and returns to `app_bootstrap_main`.
- Evidence: `startup-call-chain.md`, function-map rows for `app_bootstrap_main`,
  `bootstrap_init_shell_window_services`, `shell_install_global_controller`,
  `shell_service_pump_iteration`, `shell_load_graphics_config_or_init_defaults`,
  `shell_reset_display_runtime_defaults`, and related graphics setup helpers.
- Open Questions: whether gameplay or in-engine world stepping later escapes this bootstrap-owned
  shell loop entirely, or whether gameplay entry still rendezvous with the same outer coordinator
  before the shell bundle is destroyed.

## Shell UI Command and Deferred Work Flow

- Roots: shell callback paths that converge on `shell_dispatch_ui_command` at `0x00464410`.
- Trigger/Cadence: event-driven UI command dispatch plus deferred-message queue flushing during
  shell activity.
- Key Dispatchers: `shell_dispatch_ui_command`, `shell_enqueue_deferred_work_message`,
  `shell_post_deferred_message_type5`, `shell_post_deferred_message_type6`,
  `shell_enqueue_deferred_message_type4`, `shell_enqueue_deferred_message_type1`.
- State Anchors: shell object at `0x0062be68`, queue roots around `[this+0x11369d]`,
  `[this+0x1136a1]`, and `[this+0x1136a5]`, global routing gates at `0x006d4034`, and the separate
  detail-panel controller rooted at `0x006d0818`.
- Subsystem Handoffs: routes into graphics config, scenario-text export, overlay generation,
  multiplayer UI, shell detail windows such as `EditorPanel.win` and `TrainDetail.win`, and
  presentation-facing deferred work later drained by `shell_service_frame_cycle`.
- Evidence: function-map shell rows around `0x00464410`, `0x004d4500`, `0x004ddbd0`, and
  `0x0051f1d0..0x0051f460`.
- Open Questions: whether the shell command dispatcher is also used by hotkeys or only by UI
  callback tables; the current `0x006d0818` detail-panel path looks shell-only and does not yet
  explain gameplay world entry.

## Presentation, Overlay, and Frame Timing

- Roots: the bootstrap-owned `shell_service_pump_iteration` at `0x00483f70`, the shell-state service
  pass `shell_state_service_active_mode_frame` at `0x00482160`, the installed global shell
  controller at `0x006d4024`, the pending frame-cycle owner `shell_service_frame_cycle` at
  `0x00520620`, and the frame-time history path under `shell_update_frame_time_history` at
  `0x0051fd70`.
- Trigger/Cadence: recurring bootstrap-owned shell service work once the active mode, controller
  window, and display runtime are live; special modal or content-building paths can also force
  immediate frame servicing inside that broader cadence.
- Key Dispatchers: `shell_service_pump_iteration`, `shell_state_service_active_mode_frame`,
  `shell_service_frame_cycle`, `shell_refresh_presentation_frame`,
  `shell_update_frame_time_history`, `shell_get_smoothed_frame_scalar`,
  `shell_set_gamma_ramp_scalar`, and overlay builders such as
  `shell_queue_single_world_anchor_overlay`, `shell_queue_world_anchor_overlay_list`, and
  `shell_queue_indexed_world_anchor_marker`.
- State Anchors: shell state at `0x006cec74`, active mode pointer `0x006cec78`, shell frame history
  ring at `0x006d403c`, display/runtime state inside the controller block near `[this+0x114282]` and
  `[this+0x11428a]`, presentation service pointer at `[this+0x0c]`, and the native controller window
  handle at `[this+0x00]`.
- Subsystem Handoffs: the bootstrap-owned pump runs shell-bundle polling and shell-state maintenance
  before the shell-state pass synchronizes active-mode helpers and modal-status work and dispatches
  the controller frame cycle, which then consumes world/object state for overlays and presentation
  refresh, uses the controller window handle for one-time `ShowWindow` and related UI interaction,
  and drains the deferred work queues at the end of the cycle.
- Evidence: function-map rows for `shell_service_pump_iteration`,
  `shell_state_service_active_mode_frame`, `shell_service_frame_cycle`,
  `shell_flush_deferred_work_queues`, frame history, gamma ramp, world-anchor overlay builders, and
  graphics runtime helpers.
- Open Questions: how simulation cadence rendezvous with the shell presentation cadence once
  gameplay takes over and whether gameplay stepping exits this shell-owned controller path entirely.

## Map and Scenario Content Load

- Roots: `shell_map_file_entry_coordinator` at `0x00445ac0`, the larger active-mode profile owner
  `shell_active_mode_run_profile_startup_and_load_dispatch` at `0x00438890`, the shell-mode
  switcher `shell_transition_mode` at `0x00482ec0`, the first grounded world-entry branch
  `world_entry_transition_and_runtime_bringup` at `0x00443a50`,
  `shell_map_file_world_bundle_coordinator` at `0x00445de0`, reference-database setup via
  `map_bundle_open_reference_databases` at `0x00444dd0`, and narrower loaders such as
  `map_load_geographic_label_database` and `map_load_city_database`.
- Trigger/Cadence: shell tutorial launch, editor or detail-panel file actions through `fileopt.win`,
  map-scenario open paths, and scenario-text export batch commands.
- Key Dispatchers: `shell_map_file_entry_coordinator`,
  `shell_active_mode_run_profile_startup_and_load_dispatch`, `shell_transition_mode`,
  `world_entry_transition_and_runtime_bringup`, `world_runtime_release_global_services`, `shell_map_file_world_bundle_coordinator`,
  `map_bundle_open_reference_databases`, `map_load_geographic_label_database`,
  `map_load_city_database`, `scenario_text_export_build_language_file`,
  `scenario_text_export_report_language_file`, `scenario_text_export_batch_process_maps`.
- State Anchors: shell-side file staging buffers at `0x0062bee0` and `0x0062bec4`, shell and mode
  globals at `0x006cec74` and `0x006cec78`, world object root `0x0062c120`, map bundle state
  allocated through `0x00530c80`, and geography tables rooted at `0x0062b2fc` and `0x0062b268`.
- Subsystem Handoffs: the shared `fileopt.win` dialog rooted at `0x004dc670` now looks like the
  shell-side selector above the two broad file coordinators. Its message handler sets `0x006d07f8`
  for the load or restore side or `0x006d07ec` for the save or package side before the detail-panel
  transition manager routes into `shell_map_file_entry_coordinator` or
  `shell_map_file_world_bundle_coordinator`. The former unresolved third flag at `0x006d07f0` is now
  accounted for too: it escapes into the standalone `SettingsWindow.win` path through
  `shell_open_settings_window` rather than another map or save verb. The broad coordinators now hand
  their interactive work through the shared `filerqst.win` helper at `0x004dd010`, and that helper
  gives the extension split a firmer shape. The paired editor-map path is now grounded as `.gmp`
  through load mode `4` and save mode `3`. The remaining non-editor families are no longer anonymous
  either: `.gmc` is the campaign-scenario branch, backed both by the campaign-screen resignation
  prompt on `0x006cec7c+0xc5` and by the numbered `%s%02d.gmc` save helper at `0x00517c70`; `.gmx`
  is the sandbox branch, backed by the shell-side `The briefing is not available in sandbox games.`
  restriction on `0x006cec7c+0x82`; and the default `.gms` branch is therefore the standalone
  scenario family. When a live runtime world is already active the same helper bypasses those
  non-runtime extensions and forces the `.smp` runtime-state branch instead. The auxiliary save-side
  mode `11` is tighter now too: it still maps to `.gmt`, but instead of looking like another
  gameplay save family it conditionally diverts into the same `.gmt` preview-surface pipeline owned
  by the Multiplayer preview dataset object at `0x006cd8d8`, and only falls back to the normal
  reference-bundle path when that dataset object is absent. The shell-side mode owner above those
  file coordinators is clearer now too. `shell_transition_mode` no longer reads like a generic mode
  switch: its ABI is now grounded as a `thiscall` with two stack arguments because the body reads
  the requested mode from `[esp+0x0c]` and returns with `ret 8`. The grounded world-entry
  load-screen call shape is `(4, 0)`, not a one-arg mode switch. The second stack argument is now
  tighter too: current local evidence reads it as an old-active-mode teardown flag, because the
  `0x482fc6..0x482fff` branch only runs when it is nonzero and then releases the prior active-mode
  world through `0x434300`, `0x433730`, and the common free path before clearing `0x006cec78`.
  The later world-entry reactivation branch correspondingly uses `(1, esi)` rather than `(1, 0)`.
  The current live hook probes now push the remaining auto-load gap much later too: on the
  hook-driven path `shell_transition_mode(4, 0)` returns cleanly, and the full old-mode teardown
  stack under `0x5389c0` now returns too, including `0x5400c0`, the `0x53fe00 -> 0x53f860`
  remove-node sweep over `[object+0x74]`, and the nearby mode-`2` teardown helper `0x00502720`.
  The same live run now also reaches and returns from `shell_load_screen_window_construct`
  `0x004ea620` and the immediate shell publish through `0x00538e50`.
  Its constructor jump table is tighter now too: mode `1` is not the direct `Game.win`
  constructor, but the startup-dispatch arm rooted at `0x483012`; mode `2` enters `Setup.win`,
  mode `3` enters `Video.win`, mode `4` enters the plain `LoadScreen.win` branch at `0x4832e5`,
  mode `5` enters `Multiplayer.win`, mode `6` enters `Credits.win`, and mode `7` enters
  `Campaign.win`. The important static correction is that the startup-runtime slice
  `0x004ea710 -> 0x0053b070(0x46c40) -> 0x004336d0 -> 0x00438890` belongs to mode `1`, not mode
  `4`. Mode `4` only constructs and publishes the `LoadScreen.win` object through `0x004ea620`
  and `0x00538e50`. The older hook-driven `(4, 0)` path therefore was not mysteriously skipping
  the startup-runtime object; it was entering the wrong jump-table arm for that work. The caller
  split above that owner is tighter now too:
  `world_entry_transition_and_runtime_bringup` reaches the same owner at `0x443b57` with `(0, 0)`
  after dismissing the current shell detail panel and servicing `0x4834e0(0, 0)`, while the
  saved-runtime path at `0x446d7f` does the same before immediately building the `.smp` bundle
  payloads through `0x530c80/0x531150/0x531360`. That makes the `LoadScreen.win` startup lane the
  only currently grounded caller that enters `0x438890` with `(1, 0)` instead of `(0, 0)`. The
  remaining runtime uncertainty is narrower now too: the plain-run logs still show the plain
  `LoadScreen.win` state under `(4, 0)`, and the corrected allocator-window run now reinforces the
  same read because the post-construct allocator stream stays empty instead of showing the expected
  `0x46c40` startup-runtime allocation. The first lower allocator probe on `0x005a125d` was not
  trustworthy because that shared cdecl body sits behind the thunk and the initial hook used the
  wrong entry shape, and the first direct thunk hook was also not trustworthy because a copied
  relative-`jmp` thunk cannot be replayed through an ordinary trampoline. But the later corrected
  thunk run plus the jump-table decode now agree: the next meaningful hook-driven test is mode
  `1`, not mode `4`.
  `mode_id = 2`, and it never advanced into `ready gate passed`, staging, or transition. So that
  run did not actually exercise the `0x0053b070 -> 0x004336d0 -> 0x00438890` subchain at all.
  The next runtime pass now lowers the ready-poll defaults to `1` and `0` and adds an explicit
  ready-count log so the mode-`4` startup lane either stages immediately or shows exactly how far
  the gate gets. That adjustment worked on the next run: the hook now stages and completes the
  `shell_transition_mode` path again, with `LoadScreen.win` construction and publish returning
  cleanly. But the post-publish startup subchain is still unresolved: there is still no trusted
  `0x46c40` allocator hit, no direct `0x004336d0` entry, and no direct `0x00438890` entry. So
  the next clean runtime boundary is the tiny `LoadScreen.win` scalar setter at `0x004ea710`,
  which sits immediately before the `0x0053b070` allocation in the static mode-`4` branch. The
  immediate next runtime check is even more concrete than the helper hook, though: inspect the
  state that `0x004ea710` should leave behind. The hook now logs the post-transition
  `LoadScreen.win` singleton, its field `[+0x78]`, `0x006cec78`, the shell state's `[+0x0c]`
  active-mode object field, and the startup selector. If `0x004ea710` really ran on the mode-`4`
  branch, `[LoadScreen.win+0x78]` should no longer be zero after `shell_transition_mode` returns.
  The latest run answered that directly: after transition return, `field_active_mode_object` is
  still the `LoadScreen.win` singleton, `0x006cec78` is still null, `[LoadScreen.win+0x78]` is
  still zero, and the startup selector is still `3`. So the current best read is that RT3 is
  still parked in the plain `LoadScreen.win` state at transition return rather than having entered
  the separate runtime-object path yet. That shifts the best next runtime boundary from “deeper
  inside `shell_transition_mode`” to “what later active-mode service tick, if any, promotes the
  load-screen object into the startup-dispatch path.” The next run now logs the first few
  shell-state service ticks after auto-load is attempted with that same state tuple
  (`0x006cec78`, `[shell_state+0x0c]`, `0x006d10b0`, `[LoadScreen.win+0x78]`, selector), so the
  next question is very narrow: does one later service tick finally promote the plain
  `LoadScreen.win` state into the startup-runtime object path, or does it stay frozen as-is? The
  internal selector split in `0x438890` is tighter now too: `[0x006cec7c+0x01]` is a separate
  seven-way startup selector, not the shell mode id. Values `1` and `7` load `Tutorial_2.gmp` and
  `Tutorial_1.gmp`, values `3/5/6` collapse into the same profile-seeded file-load lane through
  `0x445ac0([0x006cec7c]+0x11, 4, &out_success)`, value `2` is a world-root initialization lane
  that allocates `0x0062c120` and then forces selector `3`, and value `4` is the setup-side world
  reset or regeneration lane that rebuilds `0x0062c120` from `0x006d14cc/0x006d14d0` before later
  world setup continues. The write side is tighter now too: `Campaign.win` writes selector `6`,
  `Multiplayer.win` writes selector `3` on one pending-status path, and the larger `Setup.win`
  dispatcher writes selectors `2`, `3`, `4`, and `5` on its validated launch branches. That makes
  the file-load subfamily read less like one generic save-open branch and more like a shared
  profile-file lane reused by setup, multiplayer, and campaign owners. The world-entry owner
  boundary is tighter now too: `world_entry_transition_and_runtime_bringup` at `0x00443a50` no
  longer stops at the initial shell transition and world allocation head. The same grounded
  function continues through the larger post-load generation tail up to `0x00444dc2`, which means
  the later `Setting up Players and Companies...` and neighboring post-load passes are not
  floating raw callsites after all. That same owner now clearly covers the event-runtime refresh
  through `0x433130`, chairman-profile materialization through `0x437220`, neighboring route and
  tracker refresh families, and the one-shot kind-`8` runtime-effect service through `0x432f40`
  before clearing shell-profile latch `[0x006cec7c+0x97]`. The `Setup.win` dispatcher
  is less opaque now too: the early `0x0bc1..0x0c24` family is mostly fixed submode selection above
  `0x00502c00`, except for the separate `0x0bc2/0x0bc5/0x0bc6/0x0bc7` shell-open quartet above
  `0x00501f20`; `0x0c1f` is the settings-window escape; `0x0c1e/0x0c20/0x0c22` are direct shell
  requests into `0x00482150`; the fixed submode buttons now have concrete lower targets such as
  `0x0bc1/0x0bc8 -> 15`, `0x0bc3 -> 16`, `0x0bc4 -> 1`, `0x0c80 -> 13`, `0x0c1c -> 17`,
  `0x0c1d -> 2`, `0x0c24 -> 14`, `0x0c81 -> 14`, `0x0c82 -> 6`, `0x0c83 -> 10`, and
  `0x0c84 -> 12`; the
  `0x0ce6/0x0ce7/0x0d49/0x0d4a/0x0e82/0x0e83` branches are bounded list or slider adjustments on
  staged setup fields; and the later `0x0dca/0x0dcb/0x0de9/0x0df3/0x0e81/0x0f6f/0x0f70` controls
  are the explicit selector-writing launch buttons rather than one anonymous validated-launch blob.
  The constructor-side callbacks are tighter too: control `0x0ce8` is a table-driven payload-label
  draw callback above `0x00502030`, not another launch root, and controls `0x0e86` and `0x0e87`
  do not select more setup roots; they update the persisted shell-state selector pairs at
  `[0x006cec74+0x233/+0x237]` and `[0x006cec74+0x23b/+0x23f]` through `0x00502160` and
  `0x005021c0`, then immediately save config through `0x00484910(1)`. The constructor body is
  tighter too: it seeds the initial `Setup.win` state by running `0x502910`, `0x502550`, and
  `0x502c00(1)` before the user interacts with the window, installs `0x0c80..0x0c86` and
  `0x0f6f..0x0f71` as homogeneous button bands, and treats `0x0e88` as one separate special
  control with retuned float fields rather than another ordinary launch root. The remaining
  optional constructor child `0x0bd0` is tighter now too: it is built from a separate template
  block and optional owned heap object before registration, not another hidden setup-root button.
  The generic shell helper layer beneath that constructor is tighter now too: `0x53fa50` is the
  shared resource-bind and child-list initialization helper, `0x53f830` is the child-control
  lookup-by-id helper over the intrusive list at `[this+0x70]`, `0x558130` is the child-control
  finalizer that stamps the owner pointer and resolves localized captions before the control goes
  live, and `0x53f9c0` is the ordered child-control registration helper used by the optional
  `0x0bd0` branch and other shell dialogs.
  The submode selector itself is tighter now too because its button-state lane is mostly decoded:
  `0xbc5` tracks submode `15`, `0xbc6` tracks `16`, `0xbba` tracks `2`, `0xbbb` tracks `3`,
  `0xbc3` tracks `13`, `0xbbc` groups `3/4/5`, `0xbbd` tracks `4`, `0xbbe` tracks `5`, `0xbbf`
  groups `6/12/14`, `0xbc0` tracks `7`, `0xbc1` tracks `8`, `0xbc2` tracks `9`, `0xe75` tracks
  `10`, and `0xf6e` tracks `17`. RT3.lng and the setup art families now also make several of those
  top-level roots read less like anonymous ids and more like real menu panels: submode `1` is the
  strongest current landing-panel fit, `2` is the `Single Player` root, `7/8/9` are the
  `Editor` / `New Map` / `Load Map` family, `15` is `Extras`, and `17` is `Tutorial`. By
  elimination against the separate shell `Credits.win` mode, the remaining top-level `Setup.win`
  roots now most safely read as `13 = Multi Player` and `16 = High Scores`.
  The file-backed side is tighter too: `0x502c00` now maps submodes exactly as `4 -> dataset 5`,
  `9 -> 4`, `6 -> 8`, `10 -> 6`, `12 -> 10`, and `14 -> 9`, so the saved-game-backed family is
  no longer one blurred list pane but a small set of stable dataset variants above
  `0x4333f0/0x4336a0`.
  The file-list builder under that pair is tighter too: `0x4333f0` no longer just emits unsorted
  `0x25a`-byte rows with raw names at `+0x0` and normalized labels at `+0x12d`. After the scan it
  now clearly re-enters `0x51dc60`, which is a generic adjacent-swap insertion sort over fixed
  records; in this setup-side caller it receives `record_size = 0x25a` and `key_offset = 0x12d`,
  so the resulting `Setup.win` rows are sorted by display label rather than by the raw filename.
  The file-backed header split is tighter too: `0x5027b0` now maps the top header-control ids as
  `4 -> 0xd4b`, `9 -> 0xde8`, `6/12/14 -> 0xdf2`, and `10 -> 0xe85`. RT3.lng closes one earlier
  mistake here: those values are local setup control or resource ids, not localized text ids.
  The setup art bundle now tightens that family split one step further too: under `rt3_2WIN.PK4`
  the distinct file-backed setup art families are the shared `Setup_Load` lane and the separate
  `Setup_Sandbox` lane, which matches the selector-side evidence that mode `10` is the
  sandbox-backed `new` list while mode `12` is its `load` sibling. Combined with the builder at
  `0x4333f0`, that shows only submodes `4` and `10` using the alternate localized-stem list-label
  path; `6`, `9`, `12`, and `14` keep the direct filename-normalization lane.
  The `rt3_2WIN.PK4` extraction path is grounded a bit more cleanly now too: current `pack4`
  samples use a shared `0x03eb` header, a fixed `0x4a`-byte directory entry stride, and a payload
  base at `8 + entry_count * 0x4a`. In the checked UI bundle the entry table is contiguous and
  `Campaign.win` extracts cleanly at directory index `3` with payload length `0x306a`.
  The extracted `.win` payload family now has one narrow shared shape too: `Campaign.win`,
  `CompanyDetail.win`, and `setup.win` all share the same first `0x50` bytes at offsets
  `0x00`, `0x0c`, `0x10`, `0x14`, `0x34`, `0x38`, `0x40`, and `0x48`, while
  `CompanyDetail.win` and `setup.win` also carry an inline root `.imb` name immediately at
  `0x51`. Current resource scans show `Campaign.win` embedding the `litCamp*/Ribbon*` family,
  `CompanyDetail.win` embedding mainly `CompanyDetail.imb`, `GameWindow.imb`, and `Portrait.imb`,
  and `setup.win` embedding the broader `Setup_Background/Buttons/New_Game/Load/Sandbox` art
  families. The control records between those strings are still undecoded, but the resource-record
  shell itself is tighter now: all checked `.win` samples use the same three-word prelude prefix
  `0x0bb8, 0x0, 0x0bb9`, and the fourth prelude word matches `resource_name_len + 1`. The next
  word after the terminating NUL then behaves like a per-record selector lane. In `setup.win`
  the dominant `Setup_Buttons.imb` family alternates between `0x00040000` and the incrementing
  `0x00010c1c..0x00010c86` series with dominant inter-record strides `0xb7/0xdb`; in
  `Campaign.win` the `litCamp*/Ribbon*` family carries the incrementing `0x0004c372..0x0004c38e`
  selector block with dominant `0x158/0x159` and `0xb2/0xb3` strides. That campaign lane is now
  directly aligned to the executable-side control ids too: the low 16 bits of
  `litCamp1..16` map exactly to `0xc372..0xc381`, and the low 16 bits of `Ribbon1..16` map
  exactly to `0xc382..0xc391`, matching the `Campaign.win` progress and selector control bases
  already grounded from `RT3.exe`. The fuller selector export now tightens the auxiliary families
  too: `litArrows.imb` covers `0xc36c..0xc371` exactly and `litExits.imb` covers
  `0xc397..0xc39a` exactly, matching the constructor-side six-control arrow strip and four-control
  exit strip. The second post-name dword is tighter now too: its middle 16-bit lane groups those
  same `Campaign.win` records under `0xc368`, `0xc369`, `0xc36a`, and `0xc36b`, which matches the
  four page-strip controls and cleanly buckets the first five campaign entries, the next five, the
  next three, and the final three under the same page families. There are still no `.imb`
  selector records for `0xc393..0xc396` or `0xc39b`, which makes those message-side page-write
  controls look more like structural buttons than art-backed repeated resource records.
  The grouped `3/4/5` family is narrower now too: `0x0ce5` is no longer part of it, because that
  control writes selector `3` and then selects submode `9` as the `Load Map` sibling. The nearby
  `0x0dcb` branch instead conditionally selects submode `5` or `3`, which keeps `3` as the
  strongest current `New Game` / `Options` companion and `5` as the strongest current `Sandbox`
  companion. The file-backed single-player side is tighter in the same way now: modes `4` and `10`
  are the only siblings using the alternate localized-stem row-label path, so they now read most
  safely as the two setup-local template or profile list variants rather than ordinary save lists.
  Mode `10` is the stronger one of the pair because neighboring validated launch control `0x0e81`
  both routes into selector `5` and sets sandbox byte `[0x006cec7c+0x82] = 1`, which makes it the
  strongest current fit for the setup-local `New Sandbox` list. The distinct `Setup_Sandbox` art
  family in `rt3_2WIN.PK4` now reinforces that same split one step further, which makes mode `12`
  the strongest closed fit for the paired `Load Sandbox` lane; mode `4` is therefore the strongest
  remaining non-sandbox peer in that same pair and now most safely reads as the setup-local `New
  Scenario`-style chooser. Modes `6`, `12`, and `14` now tighten one step further as the three
  selector-`3` direct-filename setup-local `load` siblings because they stay on the direct
  filename-normalization lane, share the same `0xdf2` header family, and clear the same
  presence-style latch `[0x006cec7c+0x97]`; mode `14` is the strongest current landing panel for
  that cluster because `0x0c24` jumps to it directly while `0x0c82` and `0x0c84` only reach the
  sibling modes `6` and `12` from inside the same load family. Current control-pairing and
  setup-art evidence now make `12 = Load Sandbox` the strongest closed per-submode assignment. The
  remaining non-sandbox pair is closed now too: the deeper bundle filter at `0x433260`
  distinguishes dataset `9` from dataset `8` by one extra nonzero payload-flag family, and the
  editor-side metadata path now grounds `[0x006cec78+0x66de]` as the direct `Campaign Scenario`
  checkbox bit because `editorDetail.win` ties control `0x5b6e` to localized ids `3160/3161`.
  That makes dataset `9` the campaign-designated load family and dataset `8` the ordinary scenario
  load family, so `14 = Load Campaign` and `6 = Load Scenario` now read as grounded rather than
  residual. `0x502910` is
  tighter in a
  corrective way too: it is not a mode-`3`-only helper after all, but the shared non-file-backed
  payload panel that formats
  `0xcf3/0xcf4/0xcf5/0xd4f`, mirrors option byte `[0x006cec7c+0x7d]` into `0x0ce9..0x0ced`,
  rebuilds row host `0x0ce8` from payload bytes `[+0x31b/+0x31c]`, and mirrors live row markers
  into `[0x006cec7c+0x87]`. That makes mode `3` just one user of the shared payload-driven panel,
  not the sole owner of it.
  The payload-helper cluster under that panel is tighter now too: `0x502220` does not just
  republish labels and the preview surface. It first re-enters
  `shell_setup_load_selected_profile_bundle_into_payload_record` `0x442400`, which clears one full
  `0x100f2`-byte setup payload record, builds a rooted path from the staged profile stem, opens the
  selected bundle through `0x530c80`, and then reads either the ordinary saved-profile chunk family
  or the map-style chunk family through `0x531150/0x531360` depending on the selected extension
  shape. Only after that does `0x502220` copy payload fields `+0x14/+0x3b2/+0x3ba/+0x20` into the
  staged runtime profile through `0x47be50`, which in turn normalizes the payload category bytes at
  `[payload+0x31a + row*9]` and the local marker-slot bytes at `[payload+0x2c9..]` through
  `0x47bc80`. The copied-field consumer split is tighter now too: payload `+0x14` becomes staged
  profile `[0x006cec7c+0x77]`, which is the visible setup scalar later formatted into controls
  `0x0e84` and `0x0d4f` and adjusted by the `0x0d49/0x0d4a` pair; payload `+0x3b2` becomes
  `[0x006cec7c+0x79]`, the live-row threshold that the payload-row draw callback uses to choose
  style slot `0x18` versus `0x19`; and payload `+0x3ba` becomes `[0x006cec7c+0x7b]`, the current
  scroll or row-index lane adjusted by the `0x0ce6/0x0ce7` pair. So the known setup-side payload
  consumers still stop well before the later candidate table, but the early copied lanes are no
  longer anonymous. The adjacent region-side worker family is tighter in a negative way too: the setup
  payload path now gives one useful upper bound on the newer candidate-availability source block
  too. The map-style setup loader is definitely pulling chunk families `0x0004/0x2ee0/0x2ee1`
  into one large `0x100f2`-byte payload record, and the fixed `0x6a70..0x73c0` candidate table
  clearly lives inside the same broad file family; but the grounded setup-side consumers we can
  actually name after that load still only touch earlier payload offsets such as `+0x14`,
  `+0x20`, `+0x2c9`, `+0x31a`, `+0x3ae`, `+0x3b2`, and `+0x3ba`. So the current evidence is
  strong enough to say the candidate table is probably housed inside the setup payload family, but
  not yet strong enough to name one setup-side consumer that reads the `0x6a70` header or the
  fixed-width entries directly. The newer fixed-offset compare pass tightens that lower setup slice
  too: across the checked map/save pairs `Alternate USA.gmp -> Autosave.gms`,
  `Southern Pacific.gmp -> p.gms`, and `Spanish Mainline.gmp -> g.gms`, the known setup payload
  lanes `+0x14` and `+0x3b2` are preserved map-to-save on the same scenario-family split as the
  later candidate-table headers (`0x0771/0x0001`, `0x0746/0x0006`, `0x0754/0x0001`), while
  `+0x3ae` stays fixed at `0x0186` and `+0x3ba` stays fixed at `1` across all six files. By
  contrast, `+0x20` does not survive as one shared source value (`0xd3 -> 0xb4`,
  `0x6f -> 0x65`, `0xe3 -> 0x78` across those same pairs). So the current best read is that the
  setup payload mixes preserved scenario metadata and later save-variant state well before the
  `0x6a70` candidate table, rather than acting as one uniformly copied prelude.
  The adjacent region-side worker family is tighter in a negative way too: the setup
  payload loader is now clearly separate from the broader region-building and placement cluster
  around `0x422320..0x423d30`, whose current grounded helpers now include `0x422320`, `0x4228b0`,
  `0x422900`, `0x422a70`, `0x422be0`, `0x422ee0`, `0x4234e0`, `0x4235c0`, and
  `world_region_refresh_cached_category_totals_and_weight_slots` `0x423d30` rather than one hidden
  setup-only panel. The leading region helper is no longer unnamed either: `0x422320` is now
  bounded as the recurring cached-structure-scalar normalization pass that writes
  `[region+0x2e2/+0x2e6/+0x2ea/+0x2ee]`, while `0x422a70` is the shared placement-validation and
  commit gate beneath both the per-region worker and one second world-side placement loop. The
  neighboring `0x4234e0` accessor is tighter too: it is the shared projected structure-count scalar
  query by category that later feeds both the per-region placement family and the map-editor city
  count stats report. So the remaining gap is no longer “what are these setup payload helpers
  doing,” but only how aggressive we want to be when naming the last top-level setup roots from
  mostly RT3.lng and asset-side evidence.
  The adjacent summary helper is tighter too: `0x502550` is not another hidden submode owner. It
  republishes the staged path tail in `0xe7f`, the scalar summary in `0xe84`, the two persisted
  selector lists in `0xe86/0xe87`, and the config toggles in `0xe88/0xe89/0xe8a`.
  The remaining top-level gap is cleaner now too: submode `16` still has no distinct downstream
  helper or launch branch in the local selector/refresh family, but it is no longer a blank bucket.
  Current evidence now bounds it as the `0x0bc3 -> 16` top-level button whose visual-state lane is
  surfaced through control `0xbc6`, and the strongest residual fit is `High Scores` because
  `Credits` already lives in separate shell mode `6`.
  The validated launch lane is tighter now too: it no longer just writes selector `3` or `5` as
  one undifferentiated blob, and it no longer includes `0x0ce5` or `0x0dcb`. `0x0ce5` is the
  `Load Map` selector because it writes selector `3` and then selects submode `9`, while `0x0dcb`
  is the later conditional `5/3` companion-selector sibling rather than a file launch. The actual
  validated staged-profile lane is now bounded more narrowly: `0x0cf6` and `0x0e81` are the
  selector-`5` siblings, while the neighboring selector-`3` validated lane is at least shared by
  `0x0de9` and `0x0df3`; the shared bridge at `0x4425d0` then forces `[0x006cec7c+0xc5] = 1`,
  mirrors payload bytes into `[profile+0xc4]`, `[profile+0x7d]`, and `[profile+0xc6..+0xd5]`, and
  only then issues shell request `0x0cc`. The file-side staging bytes in that bridge are now
  tighter too: across the checked `Alternate USA`, `Southern Pacific`, and `Spanish Mainline`
  map/save pairs, payload `+0x33` stays `0`, but payload `+0x22` and token block `+0x23..+0x32`
  do not preserve the earlier map-to-save pairing seen at `+0x14/+0x3b2`. Instead they split by
  the finer file family, with examples `Alternate USA.gmp = 0x53 / 0131115401...` versus
  `Autosave.gms = 0xae / 01439aae01...`, `Southern Pacific.gmp = 0xeb / 00edeeeb...` versus
  `p.gms = 0x21 / 0100892101...`, and `Spanish Mainline.gmp = 0x5b / 0044f05b...` versus
  `g.gms = 0x7a / 0022907a...`. So the validated launch bridge now looks more like a file-family
  staging lane than a simple copy-forward of the earlier setup summary fields. The destination-side
  consumers are tighter now too: `[profile+0xc4]` is no longer just an unnamed staged byte, but the
  campaign-progress slot later consumed by the numbered `%s%02d.gmc` save helper `0x00517c70`;
  `[profile+0x7d]` is the same compact option byte mirrored back into the `Setup.win` option
  controls `0x0ce9..0x0ced`; and the campaign-side selector block is no longer only a one-byte
  anchor. Direct `RT3.exe` disassembly of the campaign-side dispatcher at `0x004b89c0` now shows
  the exact mirror shape: when the local campaign-page selector `[window+0x78] <= 4`, the helper
  writes one highlighted progress control `0x0c372 + [profile+0xc4]` and then mirrors the full
  sixteen-byte band `[profile+0xc6..+0xd5]` into controls `0x0c382..0x0c391` through repeated
  `0x540120` calls. The same body also treats `[profile+0xc4]` as an index into the fixed
  sixteen-entry scenario-name table at `0x00621cf0`, whose observed entries include `Go West!`,
  `Germantown`, `Central Pacific`, `Texas Tea`, `War Effort`, `State of Germany`, `Britain`,
  `Crossing the Alps`, `Third Republic`, `Orient Express`, `Argentina Opens Up`,
  `Rhodes Unfinished`, `Japan Trembles`, `Greenland Growing`, `Dutchlantis`, and
  `California Island`. On the launch-side branch the same helper writes startup selector `6`,
  copies the resolved campaign filename into `[profile+0x11]`, forces `[profile+0xc5] = 1`, and
  then issues shell request `0x0cc`. The lower refresh tail at `0x004b8d49..0x004b8d69` also
  shows the observed page-band split over the same progress byte: values `< 5` pair with campaign
  page `1`, values `5..9` with page `2`, values `10..12` with page `3`, and values `>= 13` with
  page `4`. So `[profile+0xc6..+0xd5]` is no longer a generic opaque span at all, but the staged
  sixteen-byte per-scenario campaign selector or unlock band consumed directly by `Campaign.win`.
  The message-dispatch side is tighter now too. The local classifier at `0x004b91d8` routes the
  control range `0x0c352..0x0c39b` through five concrete case classes: `0x0c352..0x0c361` enter
  the shared selector or launch branch, `0x0c362..0x0c367` force local page `1`,
  `0x0c368..0x0c392` force local page `2`, `0x0c393..0x0c396` force local page `0`, and
  `0x0c39b` alone forces local page `3`. That matches the constructor and refresh shape: the
  sixteen scenario selector controls live at `0x0c352..0x0c361`, the four page-strip controls
  live at `0x0c368..0x0c36b`, the six-arrow auxiliary strip lives at `0x0c36c..0x0c371`, the
  progress band lives at `0x0c372..0x0c381`, the ribbon or selector band lives at
  `0x0c382..0x0c391`, the string or voice target lane lives at `0x0c392`, the four exit controls
  live at `0x0c397..0x0c39a`, and `0x0c39b` remains the one-off special action control that
  spawns or dismisses the campaign-side companion object. The `Campaign.win` blob now exposes that
  structural split directly too: alongside the art-backed `0x0004c3xx` records it carries
  anonymous zero-name records with the same `0x0bb8 / 0 / 0x0bb9` prelude but selector words in
  the `0x0010c3xx` family. Current local extraction shows exactly
  `0x0010c352..0x0010c361`, `0x0010c362..0x0010c367`, `0x0010c393..0x0010c396`, and one
  `0x0010c39b` record, which is the same non-`.imb` band the message dispatcher treats as the
  structural selector and page-write family. Their second selector word then buckets those records
  under the same page-strip ids as the art-backed records: `0xc368` for
  `0xc352..0xc356`, `0xc362`, `0xc393`, and `0xc39b`; `0xc369` for `0xc357..0xc35b`,
  `0xc363`, and `0xc394`; `0xc36a` for `0xc35c..0xc35e`, `0xc365..0xc366`, and `0xc395`; and
  `0xc36b` for `0xc367`, `0xc35f..0xc361`, and `0xc396`. One final anonymous record at
  `0x0002c392` has no page bucket at all, which fits the already-grounded read of `0xc392` as the
  one-off string or voice target lane rather than a normal page-cell control. The anonymous body
  layout is only partially named, but one file-side distinction is already stable: the ordinary
  structural selector/page records all carry footer words `0xd3000000` and `0xd2000007` at
  relative `+0x98/+0x9c`, while the lone `0xc392` record carries `0x00000000/0x00000000` there.
  So `0xc392` is no longer just “outside the page buckets”; it is also the only current
  anonymous-record outlier in that trailing structural footer pair. The structural selector side is
  tighter now too: `0xc352..0xc361` partition exactly as `5 + 5 + 3 + 3` across page buckets
  `0xc368..0xc36b`, matching the observed campaign page bands for scenario progress values `< 5`,
  `5..9`, `10..12`, and `>= 13`. That makes the anonymous selector records the file-side mirror of
  the same campaign page split, not a separate unrelated control family. The file-order adjacency
  is tighter in the same way: `0xc352..0xc361` each sit immediately after one `RibbonN.imb`
  record and before the next `litCamp` record, which makes them the strongest current file-side fit
  for the structural selector or click-target siblings of the visible campaign ribbon controls.
  The auxiliary anonymous bands line up the same way: `0xc362..0xc367` sit inside the local
  `litArrows.imb` clusters, `0xc393..0xc396` sit inside the `litExits.imb` clusters, and
  `0xc39b` sits once between the first arrow and first exit group. So the current best read is
  that those anonymous records are the structural hitbox or action siblings of the visible arrow,
  exit, and selector art families, not an unrelated hidden control layer. The generic record
  cadence is tighter now too: in the current `Campaign.win` dump the ordinary anonymous structural
  records all span `0x0a7` bytes, while the named art-backed records cluster at `0x0b1`, `0x0b2`,
  and `0x0b3`. The only two visible outliers are the leading `0x0080c351` record at `0x0041`
  with span `0x0a3`, and the trailing `0x0002c392` record at `0x2fb9` with span `0x0b1`. That
  reinforces the current read that `0xc351` and `0xc392` are one-off structural controls flanking
  the main selector or page family rather than ordinary repeated art-backed records.
  The setup-launch corpus now tightens one corrective caveat there too: when the checked
  `Alternate USA`, `Southern Pacific`, and `Spanish Mainline` `.gmp/.gms` files are decoded with
  that same campaign-side interpretation, payload byte `+0x22` is always outside the known
  campaign progress range `0..15` (`0x53`, `0xeb`, `0x5b`, `0xae`, `0x21`, `0x7a`), so the
  ordinary validated setup lane is not simply staging a normal campaign-screen state. The paired
  token block `+0x23..+0x32` is still structurally compatible with the campaign selector band, but
  in the checked files it only populates a small recurring subset of the sixteen scenario lanes,
  chiefly `Go West!`, `Germantown`, `Central Pacific`, `Texas Tea`, and `War Effort`, with
  scenario-family-specific byte values rather than a simple `0/1` unlock bitmap. That makes the
  setup-side staging bridge look more like one shared destination layout being reused for a broader
  launch token family, not a proof that ordinary setup-launched `.gmp/.gms` content is already in
  campaign-screen form.
  Only `0x0e81` also sets `[0x006cec7c+0x82] = 1`, which is currently the strongest sandbox-side
  anchor beneath the later `.gmx` load family.
  That launch band is slightly tighter now too: `0x0dca` is the grayscale-map picker branch above
  the `TGA Files (*.tga)` / `.\Data\GrayscaleMaps` helper at `0x004eb0b0`, not another ordinary
  save-file validator. That launch band is tighter in a second way too: `0x0ddf` is not a lobby
  branch after all, but the separate windowed-mode-gated grayscale-heightmap generation path. It
  reopens the `TGA Files (*.tga)` / `.\Data\GrayscaleMaps` picker through `0x0042a970`, validates
  the chosen image through `0x005411c0`, and only then writes startup selector `2`. The fixed-
  button side is tighter too: submode `15` now aligns with the `Extras` family because it sits
  above the Readme/Weblinks shell-open quartet and the return-to-extras sibling, while submode
  `17` now aligns with the tutorial chooser because it is the only branch that later exposes
  startup selectors `1` and `7`, which RT3 uses for `Tutorial_2.gmp` and `Tutorial_1.gmp`. The
  map-root family is tighter too: submodes `7/8/9` are the only setup branch that flips the file
  root into
  `maps\\*.gm*`, with mode `8` specifically the grayscale-heightmap picker and mode `9` the
  file-backed map-list sibling.
  Submode `13` is slightly tighter now too: current local evidence shows that it stays outside
  both the dedicated file-backed pane and the mode-`3` option-heavy pane, so it is best read for
  now as one top-level non-file-backed setup branch rather than another saved-game list variant.
  The setup-side file roots are tighter now too: the shared file-list builder at `0x4333f0`
  formats either `saved games\\*.smp` or `maps\\*.gm*` from the shell-state fields at
  `[0x006cec74+0x68/+0x6c]`, with the separate `data\\tutorial` root only appearing on the
  tutorial-side `[shell+0x6c] == 2` branch. That means the `Setup.win` submode families are no
  longer one generic file pane: the ordinary setup-backed `.smp` family is broader than the
  narrower file-list pane, because modes `3/4/5/6/10/12/14` stay on the ordinary saved-game side
  while only `4/6/9/10/12/14` re-enter the dedicated file-list panel at `0x5027b0`; the `maps`
  branch is the narrower setup or tutorial launch family above the same shared record builder.
- Evidence: function-map map/scenario rows, analysis-context exports for `0x00445ac0`, `0x00445de0`,
  `0x00443a50`, `0x00434300`, and `0x00444dd0`, plus objdump string and mode-table evidence for
  `.gmp`, `.gmx`, `.gmc`, `.gms`, `.gmt`, `.smp`, `Quicksave`, the `0x004dd010` mode table at
  `0x005f3d58`, the auxiliary-owner presence check at `0x00434050`, and the `.gmt` handoff through
  `0x00469d30`, together with localized string evidence from ids `3018` and `3898`.
- Open Questions: bit `0x1` on both broad coordinators now grounds the Quicksave name seed and the
  former third `fileopt.win` flag has been ruled out as a file-flow question because it just opens
  `SettingsWindow.win`. The old broad extension question is mostly resolved: `.gmp` is the
  editor-map pair, `.gms` is the standalone scenario family, `.gmc` is the campaign-scenario family,
  `.gmx` is the sandbox family, and `.gmt` is at least bounded as an auxiliary preview-surface
  branch rather than another gameplay save family. The higher-value global question is no longer
  whether `0x00443a50` is world entry. It is where the long-lived simulation cadence takes over
  after this bring-up and whether that cadence still rendezvous with the shell-owned frame path or
  escapes into a separate gameplay loop.

## Multiplayer Session and Transport Flow

- Roots: `multiplayer_window_init_globals` at `0x004efe80`, `multiplayer_window_service_loop` at
  `0x004f03f0`, the Multiplayer.win session-event callback table built by
  `multiplayer_register_session_event_callbacks` at `0x0046a900`, the active session-event transport
  object at `0x006cd970`, the Multiplayer preview dataset object at `0x006cd8d8`, and the lower
  pending-template and text-stream helpers around `0x00597880..0x0059caf0`.
- Trigger/Cadence: shell-owned Multiplayer.win frame service plus event-driven session callbacks and
  repeated transport pump steps.
- Key Dispatchers: session-event wrappers for actions `1`, `2`, `4`, `7`, `8`;
  `multiplayer_register_session_event_callbacks`; `multiplayer_dispatch_requested_action`;
  `multiplayer_reset_preview_dataset_and_request_action`;
  `multiplayer_preview_dataset_service_frame`; `multiplayer_load_selected_map_preview_surface`;
  `multiplayer_flush_session_event_transport`; `multiplayer_transport_service_frame`;
  `multiplayer_transport_service_worker_once`;
  `multiplayer_transport_service_route_callback_tables`;
  `multiplayer_transport_service_status_and_live_routes`;
  `multiplayer_transport_text_stream_service_io`;
  `multiplayer_transport_dispatch_pending_template_node`;
  `multiplayer_transport_service_pending_template_dispatch_store`.
- State Anchors: live session globals at `0x006d40d0`, active session-event transport object at
  `0x006cd970`, status latch at `0x006cd974`, session-event mode latch at `0x006cd978`, retry
  counter at `0x006cd984`, preview dataset object at `0x006cd8d8`, preview-valid flag at
  `0x006ce9bc`, staged preview strings at `0x006ce670` and `[0x006cd8d8+0x8f48]`, Multiplayer.win
  backing block at `0x006d1270`, selector-view store root at `[transport+0xab4]`, selector-view
  generation counters at `[transport+0xab8]..[transport+0xac0]`, selector-view backing arrays around
  `[transport+0xad0]..[transport+0xae4]`, selector-view entry probe-request id at `[entry+0x50]`,
  live-state gate at `[entry+0x58]`, third-slot flag word at `[entry+0x64]`, probe-schedule tick at
  `[entry+0x68]`, last-success tick at `[entry+0x6c]`, pending-probe latch at `[entry+0x74]`,
  success generation at `[entry+0x78]`, consecutive-failure counter at `[entry+0x7c]`, rolling
  average at `[entry+0x80]`, recent sample window at `[entry+0x84..]`, bounded sample-count at
  `[entry+0x94]`, total-success count at `[entry+0x98]`, pending-template list at
  `[transport+0x550]`, dispatch store at `[worker+0x54c]`, and text-stream buffers rooted under
  `[worker+0x1c]`.
- Subsystem Handoffs: the Multiplayer.win initializer seeds the backing block at `0x006d1270`, later
  reset paths construct the separate preview dataset at `0x006cd8d8`, and the shell-owned
  active-mode frame services that dataset every frame through
  `multiplayer_preview_dataset_service_frame`. That preview side publishes roster and status
  controls through the Multiplayer window control paths, loads `.gmt` preview surfaces through
  `multiplayer_load_selected_map_preview_surface`, and is even reused by the map/save coordinator’s
  mode-`11` `.gmt` path when the dataset already exists. In parallel,
  `multiplayer_register_session_event_callbacks` allocates and registers the separate session-event
  transport object at `0x006cd970`. The shell-side bridge into that deeper transport cadence is now
  tighter: `multiplayer_window_service_loop` and neighboring reset or initializer branches call
  `multiplayer_flush_session_event_transport`, which forces one status flush and then drops into
  `multiplayer_transport_flush_and_maybe_shutdown`. That wrapper in turn runs
  `multiplayer_transport_service_frame`, the recurring pump that services one worker step through
  `multiplayer_transport_service_worker_once`, sweeps the transport-owned callback tables and field
  caches through `multiplayer_transport_service_route_callback_tables`, services both the auxiliary
  status route and the current live route through
  `multiplayer_transport_service_status_and_live_routes`, and then descends one layer farther into
  the shared GameSpy route helper `multiplayer_gamespy_route_service_frame` at `0x58d040`. The
  transport also owns a separate selector-view sidecar beneath that route cadence.
  `multiplayer_transport_ensure_selector_view_store` allocates the keyed selector-view store at
  `[transport+0xab4]`, `multiplayer_transport_find_selector_view_entry_by_name` resolves entries
  from that store, `multiplayer_transport_upsert_selector_name_entry` marks per-slot activity and
  flags inside each entry, and `multiplayer_transport_mark_selector_slot_views_dirty` plus
  `multiplayer_transport_reset_selector_view_entry_runtime_state` manage the dirty or refresh fields
  at `+0xa0`, `+0xa4`, and `+0xa8`. That selector-view maintenance path is now split more cleanly
  too. The recurring owner is `multiplayer_transport_service_selector_view_refresh_cycle`, which
  first runs the fast deferred-probe lane:
  `multiplayer_transport_collect_refreshable_selector_view_entries` walks the store through
  `multiplayer_transport_filter_insert_refreshable_selector_view_entry`, which now shows that
  `[entry+0x64]` is not a generic flag bucket but the third selector-slot flag word, parallel to
  `[entry+0x5c]` and `[entry+0x60]`. In that collector, the `g` and `a` mode-letter bits produced by
  `multiplayer_transport_parse_selector_mode_letters` become mask `0x0c` in the slot-local flag
  words, and any third-slot entry carrying those bits at `[entry+0x64]` is excluded from the
  refreshable set. Eligible entries then pass slot-aware retry timing on `[entry+0x68]`,
  `[entry+0x6c]`, `[entry+0x78]`, and `[entry+0x7c]`, after which the service loop schedules refresh
  probes through `multiplayer_transport_schedule_selector_view_entry_refresh_probe`. That fast lane
  is narrower now too: the entry-side match key `[entry+0x50]` is no longer just an opaque request
  field. The profile-key callback lanes feed
  `multiplayer_transport_parse_selector_view_probe_marker`, which decodes one local `X%sX|%d` marker
  into a probe request id plus displayed version/build integer, and
  `multiplayer_transport_arm_selector_view_probe_tracking` stores those into `[entry+0x50]` and
  `[entry+0x54]` before arming the live probe gate at `[entry+0x58]`. The current-selector callback
  root at `0x59f8b0` is now bounded as well: it resolves and upserts the active selector name,
  optionally reuses a cached `username` marker to arm probe tracking immediately, then submits the
  same profile-key bundle with selector context and forwards that selector through callback slot
  `17`, with the status-route side able to force route-mode transitions `2 -> 3 -> 4` afterward. One
  layer lower, `multiplayer_transport_handle_profile_key_query_result` at `0x596970` now bounds the
  per-key result path itself. It treats `username` as the probe-marker field, `b_flags` as the
  selector mode-letter field, and `(END)` as a real sentinel that publishes a zeroed slot-`22`
  payload instead of a marker pair. The same helper also hashes the selector-name, key-name, and
  resolved value text back into the caller table, so the profile-key bundle now looks like a real
  bounded handoff rather than an anonymous callback cloud. The deferred callback shim
  `multiplayer_transport_dispatch_selector_view_refresh_probe_result` then walks the keyed store
  through `multiplayer_transport_finish_selector_view_refresh_probe_if_matching`, which only
  completes entries whose pending latch `[entry+0x74]` is still armed and whose parsed marker
  request id `[entry+0x50]` matches the finished request. A failed result `-1` clears the pending
  latch and increments the consecutive-failure counter at `[entry+0x7c]`. A nonfailure result clears
  the pending latch, increments the success generation at `[entry+0x78]` and total-success count
  `[entry+0x98]`, clears `[entry+0x7c]`, stamps the last-success tick at `[entry+0x6c]`, appends the
  returned sample into the short rolling history at `[entry+0x84..]`, grows the bounded sample-count
  `[entry+0x94]` up to four, computes the current average into `[entry+0x80]`, and then publishes
  that averaged `ms` sample through `multiplayer_transport_enqueue_callback_slot24_record`. So the
  publication boundary is explicit and the request-id ownership is explicit: `[entry+0x80]` now
  reads as the averaged millisecond probe sample and `[entry+0x54]` as the displayed version/build
  companion integer. The adjacent route-callback side is tighter too, but it is now kept separate:
  the staged route-callback path at `0x5958e0` and the later compatibility gate at
  `multiplayer_transport_route_binding_matches_route_callback_descriptor_tuple` `0x595d00` operate
  on a compact GameSpy-style server or route descriptor family with a primary endpoint tuple at
  `[descriptor+0x00]/[+0x04]`, an optional secondary endpoint tuple at `[descriptor+0x08]/[+0x0c]`,
  string-key lookups such as `hostname` and `gamever`, and numeric-key lookups such as
  `numplayers`, `numservers`, `numwaiting`, and `gsi_am_rating`. The route-binding side uses that
  descriptor family's primary dword and host-order port plus the optional secondary tuple against
  route-binding offsets `+0x54/+0x58` and route word `+0x30`. Current evidence still does not prove
  that descriptor tuple is the same field family as the selector-view marker companion integer at
  `[entry+0x54]`. The higher compact decode owners are tighter now too: `0x5907d0` is the
  allocate-and-append lane for one self-consistent compact payload, while `0x590d00` is the keyed
  upsert-by-primary-endpoint lane that reuses an existing descriptor when possible and then notifies
  the owner callback. The route-callback-table runtime above that decode side is tighter now too:
  `multiplayer_transport_route_callback_table_construct` `0x5905e0` seeds one transport-owned
  table block, `multiplayer_transport_route_callback_table_release_decoded_schema_dictionary`
  `0x5906f0` tears down the decoded schema dictionary rooted at `[this+0x08]`,
  `multiplayer_route_callback_runtime_acquire_shared_string_copy` `0x590540` and
  `multiplayer_route_callback_runtime_release_shared_string_copy` `0x5905a0` now bound the shared
  string pool used by that decoded schema, and the higher bring-up owner `0x596090` now clearly
  splits between `[transport+0xba4]` with owner callback `0x595a40`, the local field-cache family
  `[transport+0x1724]` seeded through `0x5a08f0/0x595b60`, and `[transport+0x1164]` with owner
  callback `0x595bc0`, while
  `multiplayer_transport_route_callback_table_service_receive_decode_state_machine` `0x5908c0`
  is the current live receive/decode state machine serviced by `0x591290` in table states `2/3`.
  The callback-owner mode split above that runtime is now explicit too: append-notify `0x590370`
  publishes mode `0`, compact upsert `0x590d00` publishes mode `1`, remove-notify `0x590430`
  publishes mode `2`, and the live receive/decode path `0x5908c0` publishes modes `6`, `5`, and
  `3`.
  The route-handle lifecycle above that decode path is tighter now too: `0x590740` cleanly resets
  one table's live route plus decode-side runtime without destroying the outer object; `0x5907a0`
  is the broader destroy path that also releases the active descriptor collection; `0x590ed0`
  opens the live route handle into `[this+0x4a0]`, stages the initial outbound request, and seeds
  state `3` plus the staged receive buffer; `0x5911e0` is the state-`2/3` socket-service wrapper
  that reads new bytes, grows the staged buffer, and re-enters `0x5908c0`; `0x5912c0` is the
  one-shot send-with-reopen-retry helper; and `0x590ea0` is the shared disconnect publication and
  reset tail. The recurring service helper `0x591290` is tighter too: it now first clears the
  staged intrusive descriptor list through `0x590490` before entering the state-driven seed-or-
  receive branch. The upstream owners are tighter too: `0x5962e0` is now the field-subscription
  route-table opener above `[transport+0xba4]`, while `0x596530` is the `gsi_am_rating` reopen
  path above `[transport+0x18bc]`. On that latter branch, `0x590dc0` is now bounded as the
  state-`0` raw-endpoint seed pass over the live route handle, repeatedly pulling endpoint tuples
  through `0x58bc7e` record type `0x1f3` before stamping descriptor flag byte `0x15` with `0x11`.
  That makes the remaining source-flag meaning narrower too: current evidence now supports reading
  byte-`0x15` bit `0x1` as a primary-endpoint-seed or endpoint-only marker. In the `gsi_am_rating`
  dispatcher, clear-bit descriptors can take the richer direct transition lane, while set-bit
  descriptors are staged through the queued enrichment path and still suppress that direct
  transition even after the ready bit arrives.
  The adjacent capacity-descriptor side is tighter too: `0x595bc0` now clearly publishes a
  descriptor block from live descriptor properties `hostname`, `numwaiting`, `maxwaiting`,
  `numservers`, and `numplayers` plus three carried sidecar scalars. That sidecar at
  `[transport+0x1778]` is tighter now too: current evidence says it behaves as one cached pointer
  into the transient work-record family at `[transport+0x1780]`, because every meaningful branch
  in `0x595bc0` reads the same `+0x0c/+0x10/+0x18` metadata triplet and replay modes later consume
  the pointer through `0x5933a0`. The negative result is stronger too: local text-side xrefs still
  show no direct store to `[transport+0x1778]`, and a wider local sweep also failed to show any
  obvious `lea`-based replay-band writer. The transient-request lifecycle tightens that further:
  `0x593330/0x593370/0x593380/0x5934e0/0x5933a0` now fully bound `[transport+0x1780]`, `0x1784`,
  and `0x1788` without ever touching `[transport+0x1778]`, and the neighboring active-opcode reset
  helper `0x5929a0` is likewise scoped only to `[transport+0x17fc]`. A broader constructor and
  teardown pass tightened that further too: `0x596090`, `0x5961b0`, and `0x5962e0` all touch the
  neighboring replay-band fields without ever seeding `[transport+0x1778]`. A full-binary
  literal-offset sweep tightens it further still: the only direct `0x1778` hit in `RT3.exe` is
  the read in `0x595bc0`. One nearby ambiguity is now closed too: the
  mode-`5` mirror path in `0x595a40` and `0x595e10` does not target `[transport+0x1778]`; it
  writes `[transport+0x54]` and mirrors the same staged route companion dword only into queue-side
  slot `[transport+0x1724+0x24]` through `0x005a0940`. So the sidecar writer remains upstream of this
  leaf publisher. Mode `0` is now also tied more cleanly to the generic descriptor append-notify lane
  at `0x590370`, while mode `2` stays outside this helper as the separate
  remove-notify-and-stage path at `0x590430`. The opcode-`2` payload boundary is tighter too:
  `0x592ae0` now grounds that payload
  as a seven-dword block with an owned string slot at `+0x08`, so live mode supplies a populated
  payload while modes `3` and `5` deliberately enqueue an all-zero payload and reuse only
  the wrapper-side sidecar metadata. Those two modes are tighter now too: they are the live
  receive-state owner callbacks emitted by `0x5911e0 -> 0x5908c0`, not loose generic replay
  guesses. So those paths are better read as delayed metadata replays over one cached work record,
  not over a separate anonymous cache blob. The neighboring
  capacity-owner split is tighter now too: `0x595bc0` only stages descriptor records for modes
  `0`, `3`, and `5`; the upstream route-callback-table owner still delivers modes `1`, `2`, and
  `6`, but those are explicit no-ops in this capacity leaf. So the owner wiring itself is no
  longer the open edge; only the upstream sidecar producer remains unresolved. The neighboring
  work queue is tighter too: `0x593330/0x593370/0x593380` now bound `[transport+0x1780]` as the
  construct/clear/destroy owner family, while `0x5933a0`, `0x5934e0`, and `0x593570` ground the
  remove, allocate, and completion side over that same collection. The small sibling `0x593400` is
  tighter too: it is a pure work-record uniqueness predicate over field `+0x0c`. Its caller is
  tighter now too: `0x58d720` is an immediate-drain quiescence gate over one transport context id,
  using `0x593400` for the queued work family at `[transport+0x1780]` and `0x592970` for the
  active opcode-record collection at `[transport+0x17fc]`. The strongest current read is that
  `0x5934c0` seeds that shared drain context id first, then the transport copies it into queued
  work field `+0x0c` and active opcode-record field `+0x14` before the immediate-drain roots wait
  on one shared disappearance test rather than on a vague settle loop. The currently grounded
  roots are `0x58df20`, the neighboring formatted selector-text publish path at `0x58dfb0`, and
  callback-table registration at `0x58e200`. The active-opcode side is tighter too: `0x5927b0`
  now bounds the per-record service-and-retire path, `0x592800` the wider context-or-idle sweep,
  `0x5929a0` the remove-by-opcode-type sweep, and `0x5929f0` the narrower opcode-`3`
  field-snapshot removal keyed by the subscribed callback-pair payload. That also corrects
  `0x595b80`, whose final cleanup is an active field-snapshot purge rather than a queued-work
  drain. The adjacent route-callback descriptor-table lifecycle is tighter too: `0x590410` now
  grounds `[table+0x5bc]` as the staged intrusive descriptor-list head, `0x590430` is the generic
  remove-notify-and-stage lane, `0x590490` releases the staged list, and `0x5904d0` releases the
  active descriptor collection before tearing that staged list down. That also makes the earlier
  `0x5962e0` “release active descriptors” step explicit. The callback-table attach side now constrains the
  same work-record metadata family a little further too: `0x593650` deliberately duplicates its
  first caller metadata dword into both fields `+0x0c` and `+0x10`, while carrying the second
  caller metadata dword in `+0x18`. The lower opcode wrappers are tighter now too: `0x592a40`
  turned out to be the explicit opcode-`1` trigger wrapper whose constructor is a no-op and whose
  active-side service is `0x5913c0`, while `0x592c40` is the real `0x08`-byte explicit opcode-`5`
  binding leaf. The earlier opcode-`4` read was just the table-indexing mistake in `0x5928a0`:
  selector `4` lands on the row at `0x5e2044`, not the row at `0x5e2034`. The producer side is tighter too:
  bound-route requests, selector-text route requests, and the type-`9` text fastpath also stage
  that same triplet through `0x5934e0`, and the fastpath shim `0x593d00` now gives the cleanest
  proof of the callback split by only re-emitting the follow-on lane when `+0x10` is nonnull and
  then forwarding `(+0x10, +0x18, +0x0c)` into `0x593170` as callback function, callback
  companion, and trailing drain context. So the replay-side triplet is clearly a broader
  transport callback-wrapper family, not one fixed route-only tuple. The nearby
  field-subscription side is tighter too: `0x592b50` now clearly uses `[transport+0x1774]` as a
  cached progress percentage under `[transport+0xba4]`, and `0x5962e0` seeds that percentage to
  `1` just before the first immediate mode-`3` snapshot. The nearby route-callback-table
  lifecycle is tighter now too: `0x596090` seeds `[transport+0xba0]` as the callback-plumbing
  enable latch, clears staged payload slot `[transport+0xb50]`, and constructs the three owner
  branches rooted at `[transport+0xba4]`, `[transport+0x1164]`, and `[transport+0x18bc]`;
  `0x596210` is the recurring service sweep over those same three tables plus the local field
  cache and queued-descriptor family; `0x596060` is the explicit `gsi_am_rating` reset; and
  `0x596530` is the reopen-from-stored-label sibling above that same am-rating table. The
  matching local cleanup is tighter too: `0x5962c0` is the explicit staged route-callback payload
  clear on `[transport+0xb50]`, while `0x595ce0` now clearly resets only the capacity-descriptor
  route callback table at `[transport+0x1164]`, not the field-subscription table at
  `[transport+0xba4]`. The remaining gap on the capacity side is therefore narrower: the carried
  sidecar fields themselves now read more cleanly as the cached callback-wrapper triplet reused
  elsewhere (`drain context id +0x0c`, `callback fn +0x10`, `callback companion +0x18`), and the
  negative result is stronger too: nearby replay-band fields `[transport+0x176c]`,
  `[transport+0x1770]`, `[transport+0x1774]`, `[transport+0x177c]`, `[transport+0x1780]`, and
  `[transport+0x1784]` all have direct local owners while `[transport+0x1778]` still appears only
  as the single read in `0x595bc0`; even the broader callback-owner lifecycle now skips it while
  seeding, servicing, resetting, reopening, or tearing down those neighboring tables and caches.
  The constructor now closes that local search further: `0x58dc50` bulk-zeroes the full transport
  body and still never writes a nonzero value into `[transport+0x1778]` before later explicit
  neighbor initialization. The callback-binding owner stack now tightens that boundary too:
  `0x5934e0` stages the shared work-record metadata triplet, `0x593650` binds it into the
  callback-table worker path, and `0x593570` later consumes and republishes it, while
  `[transport+0x1778]` still appears only as the borrowed sidecar read in `0x595bc0`. So this
  edge is now locally closed, and the remaining producer looks like an upstream callback or worker
  handoff rather than one missing ordinary field store in the local cluster. The adjacent staged-route
  callback side is tighter too: `0x595860` is now bounded as the
  submit-result handler beneath `0x5958e0`, and the old `[transport+0xac0]` ambiguity there is now
  gone. That branch is using the already-grounded third selector-generation counter at `[0xac0]`
  together with target `[0xb48]` to decide whether staged route-callback traffic can push the
  multiplayer route-mode ladder from `2` into `3` and later `4`. The selector-view counter beneath
  that gate is tighter now too: `0x594e30` counts slot-`2` entries whose flag dword carries bit
  `0x20`, optionally filtered by the current transport name buffer. The selector-view mutation
  family under that same lane is tighter too: `0x594a30` is now the direct keyed-store remover,
  `0x594fb0` clears one selector-slot ownership pointer plus its slot-local flag dword and drops
  the whole entry when no slots remain, `0x595010` rekeys one selector-view entry under a new name
  while preserving the `0x40..` runtime band, and callback root `0x59f9c0` now reads as the
  sibling lane that clears one named selector-view slot, publishes callback slot `18`, and may
  still re-enter the route-mode setter from the same slot-`2` status and generation gates. The
  neighboring callback roots are tighter now too: `0x5950a0` clears one selector slot from every
  selector-view entry in the keyed store, `0x59fab0` is the rename or relabel sibling above
  `0x595010`, `0x59faf0` updates one selector slot's fixed sample-text buffer and refreshes the
  active selector object when present, and `0x59fb60` replaces one selector slot's name set,
  requests the default profile-key bundle for that slot, and publishes callback slot `20`. Slot
  `16` is tighter now too: current grounded caller `0x59f440` forwards the staged route-callback
  payload handle from `[transport+0xb50]` through `0x592ea0` just before route mode `5`. The
  last adjacent callback root in that block is tighter now too: `0x59fbd0` is the built-in
  per-slot profile-key query sibling. It resolves the caller selector name into one slot index,
  forwards the caller trio into `0x596b90`, and then publishes callback slot `28`; that lower
  helper indexes one slot-specific built-in string pair from `[transport+0x189c]` and
  `[transport+0x18ac]`, reuses the generic per-key handler `0x596970`, and only republishes slot
  `28` when that lower query path succeeds.
  The compact-header side is tighter now too: `0x58fe20` and `0x58ff20` now show that compact
  payloads always carry the primary IPv4 dword and that header bit `0x10` only gates whether the
  primary port word is inline or inherited from the owner default port. `0x58fe90` now validates
  the `0x40` inline keyed-property vector against the owner schema, and `0x58fe50` validates the
  signed-`0x80` trailing string-pair tail before decode. `0x58ff60` then grounds bit `0x02` as
  the inline secondary IPv4 dword branch, bit `0x20` as the paired secondary-port word branch with
  owner-port fallback, bit `0x08` as one still-unresolved auxiliary dword stored at
  `[descriptor+0x10]`, bit `0x40` as one inline keyed-property vector decoded through the
  property-store writers, and signed bit `0x80` as one trailing string-pair tail. The
  descriptor-state side is tighter now too: the shared queue helper at
  `0x005a09a0` stamps pending state `0x4` for the local field-cache family `[transport+0x1724]`
  and pending state `0x8` for the `gsi_am_rating` queued-descriptor family `[transport+0x1e7c]`,
  while later service through `0x005a0c80` promotes those pending tags into ready bits `0x1` and
  `0x2` in descriptor byte `[entry+0x14]`. That makes the current transport-side tests cleaner:
  `0x58d1c0` is the field-cache ready gate, `0x58d1d0` is the `gsi_am_rating` queued-descriptor
  ready gate, and `0x58d230` is the remaining flag-byte split between direct primary-endpoint
  handling at `[transport+0x18bc]` and the queued path at `[transport+0x1e7c]`. That byte-`0x14`
  story is no longer queue-only either: `0x58ff60` can also OR in bit `0x1` after the inline
  keyed-property vector and bit `0x2` after the signed string-pair tail. The flag-byte split is no
  longer purely behavioral either: current evidence now says byte `[descriptor+0x15]` bit `0x1` is
  a source-side descriptor header bit, explicitly seeded during the primary-endpoint table refresh
  around `0x590dc0` and preserved by the compact descriptor decode path at `0x58ff60`, rather than
  a queue-generated runtime state. The `gsi_am_rating` dispatcher side is tighter too: that same
  bit no longer just looks like a direct-versus-queued routing split, because `0x595e10` also uses
  it to suppress the direct `0x595dc0` transition even after queued ready bit `0x2` is present.
  The descriptor body is tighter too: `[descriptor+0x20]` is now the intrusive next-link used by
  the transport-owned primary-endpoint list headed at `[table+0x5bc]`, and `[descriptor+0x1c]` is
  now the special numeric scalar behind the current `queryid`/`ping` fallback pair. The compact-only
  auxiliary dword at `[descriptor+0x10]` is tighter in a negative way too: local xref scans now
  only show it being preserved by later generic helpers like
  `generic_record_0x1c_deep_copy_with_owned_string_at_0x08` `0x591410` and the adjacent
  callback-marshaling wrappers `0x591480` and `0x591510`, not read through any dedicated semantic
  accessor yet. The route-event dispatcher side is tighter too: the mode-`5` tails in both
  callback families do not copy a descriptor-local field but instead mirror the transport-staged
  companion dword at `[this+0x490]` into `[this+0x54]` and queue-side slot `[this+0x1724+0x24]`. The
  `gsi_am_rating` maintenance lane is tighter now too: after pruning failed descriptors it sorts
  the surviving primary-endpoint table through `0x590310` in mode `1` with key `gsi_am_rating`,
  then selects the new head through `0x590480` before re-entering the route-transition path. The
  same service loop also owns a slower sidecar lane keyed off `[entry+0xa4]`:
  `multiplayer_transport_select_stale_selector_view_progress_entry` walks the store through
  `multiplayer_transport_pick_stale_selector_view_progress_entry`, picks one stale entry whose
  progress latch `[entry+0x9c]` is clear and whose last progress tick `[entry+0x70]` is old enough,
  and then hands it to `multiplayer_transport_stage_selector_view_progress_snapshot`. That helper
  now looks more bounded too: it rebuilds the core `X%sX` marker text from `[entry+0x50]` through
  `multiplayer_transport_format_selector_view_probe_marker_core`, formats one `PNG %s %d` line
  around that marker and the entry-local averaged millisecond sample at `[entry+0x80]`, appends bounded
  selector-slot `PNG` fragments for live overlapping slots, marks progress-snapshot state in flight
  at `[entry+0x9c]`, and stamps both `[entry+0x70]` and the transport-wide throttle tick
  `[transport+0xaec]`. So the selector-view sidecar no longer looks like one undifferentiated
  refresh bucket: it has a faster deferred-probe lane plus a slower progress-snapshot lane, both
  still under the shell-owned multiplayer transport cadence. The two descriptor lanes installed by
  `multiplayer_transport_attach_callback_table_descriptor` are now tighter too. The first lane
  rooted at `0x59f5c0` can arm deferred-close state on the owner transport and then forward through
  callback slot `23`. The second lane is no longer just a loose selector-view bucket:
  `multiplayer_transport_callback_dispatch_selector_name_payload_lane` at `0x59f650` classifies
  selector payloads through `multiplayer_transport_is_selector_control_line`, routes `@@@NFO`
  control lines into `multiplayer_transport_sync_selector_view_nfo_r_flag`, and otherwise publishes
  either callback slot `13` or the split token-plus-tail callback slot `14` through
  `multiplayer_transport_split_selector_payload_token_and_tail`. That local `@@@NFO` helper is now
  bounded more tightly too: it only accepts lines ending in the literal `X\` tail, searches for the
  field marker `\$flags$\`, and then sets or clears bit `0x2` in the third selector-slot flag word
  at `[entry+0x64]` depending on whether that field contains the letter `r` before the next
  backslash. The sibling `multiplayer_transport_callback_dispatch_current_selector_payload_lane` at
  `0x59f720` first resolves the active selector through `0x5951a0`, then handles the
  current-selector variants of the same control vocabulary: `@@@NFO` continues into the same local
  `r`-flag sync helper, `@@@GML` plus mode-`3/4` payloads feed the shared control-token helper
  `multiplayer_transport_handle_gml_or_png_selector_control`, and the remaining non-control payloads
  publish callback slot `9`. That shared helper now narrows the `GML` and `PNG` split materially:
  when the token is `GML` and the tail is `Disconnected`, it requires the active selector-view entry
  to pass `multiplayer_transport_selector_view_entry_has_gml_disconnect_gate`, which currently means
  the entry participates in the third selector slot and has bit `0x20` set in `[entry+0x64]`, before
  it forces one status-pump pass, emits callback slot `16`, and re-enters route mode `5`. Its
  sibling `PNG` branch resolves a named selector-view entry from the tail text and, when that entry
  overlaps the active selector-slot ownership, refreshes selector-view runtime state through
  `0x5948f0` and republishes callback slot `25`. Alongside those dispatchers, one grounded branch at
  `0x59f560` still updates selector-view runtime state through `0x5948f0` and forwards the same
  selector-name pair through callback slot `25`, while `0x59f850` resets selector text state through
  `0x5954b0`, forwards through callback slot `19`, and when selector `2` is active in a nonterminal
  route mode re-enters `multiplayer_transport_set_route_mode` with mode `1`. The low-level route
  helper still looks like a two-part cycle:
  `multiplayer_gamespy_route_service_retry_and_keepalive_timers` handles challenge or retry pressure
  and periodic outbound control traffic around the `master.gamespy.com`, `PING`, `natneg`,
  `localport`, `localip%d`, and `statechanged` strings, while
  `multiplayer_gamespy_route_drain_inbound_packets` drains inbound datagrams and dispatches
  semicolon lines, backslash-delimited key bundles, and `0xfe 0xfd` GameSpy control packets. The
  transport-owned callback story is now narrower too. The shared route constructor
  `multiplayer_gamespy_route_construct_and_seed_callback_vector` seeds `[route+0x88]` through
  `[route+0x9c]` from the caller-supplied transport callback table, records the owner transport at
  `[route+0x104]`, and explicitly zeroes `[route+0xa0]`, `[route+0xa4]`, and `[route+0xd4]` before
  any later patch-up. For the transport-owned status route,
  `multiplayer_transport_try_connect_status_route` then patches `[route+0xa0]` through
  `multiplayer_gamespy_route_set_extended_payload_callback` to point at
  `multiplayer_transport_forward_validated_extended_route_payload` `0x00597330`, which simply
  forwards the validated payload wrapper into the owner callback at `[transport+0x17f4]` with
  context `[transport+0x17f8]`. The grounded live-route connect path at
  `multiplayer_transport_try_connect_live_route` does not currently perform any matching
  post-construction patch for `[route+0xa0]`, `[route+0xa4]`, or `[route+0xd4]`, and the higher
  route-mode state machine now looks consistent with that: `multiplayer_transport_set_route_mode`
  latches the requested small mode at `[this+0x18b8]`, then uses mode `0` for the direct-versus
  queued `gsi_am_rating` split, mode `1` for the ready-bit plus queued fallback, mode `2` for
  pending-descriptor cleanup, mode `3` for the empty-table fallback, mode `4` for deferred
  route-status recovery, and mode `5` for copying the staged route companion dword into `[this+0x54]`
  and queue-side slot `[this+0x1724+0x24]`. The current grounded mode transitions still switch by releasing route
  objects through `multiplayer_gamespy_route_release_and_free` and rebuilding them through
  `multiplayer_transport_try_connect_live_route`, not by mutating callback slots in place. The
  parser behavior is now tighter as well: semicolon lines only dispatch when
  `[route+0xd4]` is non-null, and the subtype-`6` raw fallback only dispatches when `[route+0xa4]`
  is non-null. For the currently grounded transport-owned status and live routes, those two branches
  therefore remain optional and can cleanly no-op instead of implying a hidden mandatory callback
  path. Inside the packet parser, subtype `4` is no longer an unknown callback hop: after cookie
  validation it dispatches through `[route+0x9c]`, which the transport-owned status and live routes
  seed to `multiplayer_transport_handle_validated_route_cookie_event` `0x005972c0`. That helper
  either marks route progress and re-enters `multiplayer_transport_set_route_mode`, or forwards the
  event id plus payload into the owner callback at `[transport+0x17f0]` with context
  `[transport+0x17f8]`. The surrounding status-route callback vector is tighter now too:
  `0x005970e0` publishes either the active selector text or the averaged probe sample at
  `[entry+0x80]` and otherwise falls back to owner callback `[transport+0x17e0]`;
  `0x00597180` is a straight owner-forwarding lane through `[transport+0x17e4]`;
  `0x005971b0` seeds the local status-control id list and can then notify owner callback
  `[transport+0x17e8]`; and `0x00597270` returns the third selector-slot generation counter
  `[transport+0xac0]` on its bounded local branch before falling back to owner callback
  `[transport+0x17ec]`. Subtype `6` still validates the same cookie, dedupes one 32-bit cookie or
  packet id, and then dispatches the trailing payload through the natneg-or-raw callback layer
  rooted at `[route+0xa0]` and `[route+0xa4]`. This separates the shell-frame preview refresh at
  `0x006cd8d8` from the actual transport cadence at `0x006cd970`, and also separates that transport
  cadence from the lower GameSpy route-service and packet-parser layer beneath it.
- Evidence: `function-map.csv`, `pending-template-store-management.md`,
  `pending-template-store-functions.csv`, plus objdump caller traces showing
  `multiplayer_window_service_loop` reaching `multiplayer_flush_session_event_transport` and the
  transport pump chain `multiplayer_flush_session_event_transport ->
  multiplayer_transport_flush_and_maybe_shutdown -> multiplayer_transport_service_frame ->
  multiplayer_transport_service_worker_once -> multiplayer_transport_drain_request_text_queue`.
- Open Questions: unresolved request-id semantics for `1`, `2`, `4`, and `7`; whether any
  non-mode-path helper outside the currently grounded release-and-rebuild flow ever patches
  `[route+0xa4]` and `[route+0xd4]` for the transport-owned status/live routes, or whether those
  packet families are simply unused in this stack; and how far the Multiplayer preview-dataset
  machinery is reused outside `Multiplayer.win` beyond the currently grounded `.gmt` save-mode hook.

## Input, Save/Load, and Simulation

- Roots: the shell controller window-message ingress `shell_controller_window_message_dispatch` at
  `0x0054e3a0`, the shell input-state object initialized at `0x006d4018` through
  `shell_input_state_init` `0x0054e710`, the saved-world restore path
  `world_load_saved_runtime_state_bundle` at `0x00446d40`, the live-world save path
  `world_runtime_serialize_smp_bundle` at `0x00446240`, `world_entry_transition_and_runtime_bringup`
  at `0x00443a50`, the frame-owned cadence `simulation_frame_accumulate_and_step_world` at
  `0x00439140`, the recurring `GameMessage.win` service branch through
  `game_message_window_service_if_present` `0x004e0720`, the world-facing `GameUppermost.win`
  overlay branch ensured by `shell_ensure_game_uppermost_window` `0x004e0e40` and serviced through
  `game_uppermost_window_service_world_hotspot_band` `0x004e0780`, and the lower step family rooted
  at `simulation_advance_to_target_calendar_point` `0x0040ab50` with periodic branches through
  `simulation_service_periodic_boundary_work` `0x0040a590`.
- Trigger/Cadence: shell-side input is event-driven by controller-window `WM_*` traffic while save
  or load work is triggered either directly from shell commands or through the `fileopt.win` branch
  flags into the `.smp` runtime-state family; post-bring-up world service becomes recurring once a
  world root exists at `0x0062c120`, but the current grounded top-level cadence still remains the
  shell-owned `shell_service_pump_iteration` path, which calls
  `simulation_frame_accumulate_and_step_world` directly and lets it accumulate elapsed wall-clock
  time into one or more simulation-step quanta. A second ingress is now bounded too:
  `simulation_run_chunked_fast_forward_burst` at `0x00437b20` repeatedly calls the same lower
  stepper `simulation_advance_to_target_calendar_point`, but current grounded callers put that
  helper inside the larger post-load generation pipeline `world_run_post_load_generation_pipeline`
  at `0x004384d0` under the `Seeding Economy...` phase rather than under the ordinary player-facing
  speed buttons. That setup pipeline is now clearer at the progress-banner level too: on the fuller
  setup path it first runs one preliminary named-candidate availability prepass through `0x00437743`
  before any visible progress banner is posted. After that, localized id `318`
  `Computing Transportation and Pricing...` stays visible while the pipeline runs
  `world_compute_transport_and_pricing_grid` `0x0044fb70`, the early collection-owned staging pass
  `world_rebuild_secondary_raster_derived_surface_and_companion_planes_in_rect` `0x0044e940`,
  `world_setup_building_collection_phase` `0x0041ea50`, and the conditional region pair
  `world_region_collection_seed_default_regions` `0x00421b60` plus
  `world_region_border_overlay_rebuild` `0x004882e0`. The transport/pricing side is tighter now
  too: `0x0044fb70` first routes one null-build path through the preview ensure wrapper
  `0x0044faf0`, whose deeper worker `0x0044f840` allocates a default target through
  `0x00534930`, seeds five palette entries through `0x0051de10`, maps each target pixel back into
  the live secondary raster through `0x00533970/0x00533980`, uses the low-3-bit class split plus a
  local `+/-4` neighborhood and `0x0051db80` to choose the preview color, and only then re-enters
  `0x0044e940` on the full rectangle. The later `322` side is tighter now too: the top owner
  `0x0044d410` rejects while generation counter `[world+0x2205]` is live or when `0x00449e90`
  cannot supply a surviving work rect, then forwards that rect into `0x005374d0`, `0x00533e70`,
  and `0x00537010`, notifies the shell owner at `0x0062be68`, and refreshes neighboring region or
  manager companions through `0x00421f50`, `0x00461770`, and `0x00415340`. The local
  companion-float strip under that same owner is tighter now too: `0x0044d4e0` and `0x0044d6e0`
  are sibling five-pass cross-neighbor relaxers over `[world+0x1605]`; both clamp the caller
  rectangle, average the four cardinal neighbors, subtract the current sample, scale the delta by
  one fixed coefficient and caller gain, and then feed the surviving rectangle back into
  `0x0044d410`. The first helper only checks raster bit `0x01` in `[world+0x2135]`, while the
  second adds the tighter acceptance gate `0x004499c0` and can skip the final `0x0044d410` tail
  when its caller disables that refresh. Their center-biased sibling `0x0044d880` is now bounded
  too: it seeds one baseline from the current center sample when its caller gain is positive,
  expands one square neighborhood by radius, and raises surrounding cells toward that baseline
  through the same `0x0051dc00` falloff model before tailing into `0x0044d410`. The local
  peak-oriented sibling `0x0044da70` then raises one clamped square neighborhood by quantized
  local maxima and on its optional branch also consults `0x00534f00` before keeping the larger
  peak. So the `0x0044d4e0/0x0044d6e0/0x0044d880/0x0044da70` band now reads as the local
  companion-float refinement layer immediately beneath the shared `Calculating Heights...` owner
  rather than a set of unrelated scalar writes. The default-region side is tighter too:
  one earlier class-0-only helper `0x0041fb00` now sits directly under that same family too:
  it skips nonzero `[region+0x23e]` records, rounds the region center through
  `0x00455800/0x00455810/0x005a10d0`, stamps one orientation-dependent local secondary-overlay
  pattern through `0x00534e10` plus `0x004497a0`, and then runs one bounded scored refinement pass
  through `0x0051db80`, `0x00534040`, `0x005340a0`, `0x00534100`, and `0x00533fe0`. The finalizer
  `0x00421730` then clears the per-cell region word at `[world+0x212d] + cell*4 + 1` across the
  full live world raster, seeds each live region's cached bounds fields, and repopulates that same
  raster by writing the nearest class-0 region id `[region+0x23a]` into empty or weaker cell slots
  from one bounded center-and-radius sweep. The region-profile side is tighter too: `0x0041f940`
  counts only the current subcollection entries whose backing
  candidates pass `0x0041f998`, and that smaller predicate now has one real content split instead
  of staying anonymous. Candidates whose subtype byte is not `2` pass immediately, while subtype-2
  candidates only pass when either availability word `[candidate+0xba]` or runtime recipe latch
  `[candidate+0x7ac]` is nonzero; `0x00412af0/0x00412b70` now ground the lookup step beneath both
  counters as a casefolded profile-label-to-candidate resolver over the global candidate pool
  `0x0062b268`; and the stricter year-filtered counter `0x0041f9b0` then stacks the category and
  `[profile+0x26] <= year` gates on top of that same availability test. That border
  pass is now tighter too: the
  outer owner refreshes the companion region set `0x006cfc9c` through the reset-and-assign wrapper
  `0x00487650` above the heavier record initializer `0x00487540`, then re-enters `0x004881b0` to
  refresh the raw per-region cell-count band from the live world raster, and the inner emitter
  `0x00487de0` clears prior chunked segment queues through `0x00533cf0`, scans the live region
  raster, and appends fresh border-segment records through `0x00536ea0`. The lower presentation
  helper strip under the same owner is now explicit too: `0x00533970/0x00533980` query the cached
  world-grid X/Y maxima, `0x00533ae0/0x00533af0/0x00533b00` expose the secondary-raster and
  companion byte-raster roots, and `0x00533b20/0x00533b30/0x00533b70/0x00533b90` expose the
  normalized coordinate, strip-offset, and sample-triplet tables used by shell-side overlay
  staging. If shell-state gate
  `[0x006cec74+0x174]` is set it then posts id `320` `Setting Up Buildings...` for
  `world_region_collection_run_building_population_pass` `0x00421c20`; if `[0x006cec74+0x178] > 0`
  it then posts id `321` `Seeding Economy...` for `simulation_run_chunked_fast_forward_burst`
  `0x00437b20`; only after those setup-side gates does the code post id `319`
  `Setting up Players and Companies...`. That `319` lane is no longer just a shell-state placeholder: its
  earlier hidden prepass is tighter now too: `0x00437743` is the scenario-side named
  candidate-availability seeding pass over the live candidate pool `0x0062b268`, feeding the
  override collection at `[state+0x66b2]` through `0x00434f20` before any visible banner is posted.
  That grounded write path is narrower than the static file evidence, though: the startup reset
  helper `world_runtime_reset_startup_dispatch_state_bands` `0x004336d0` explicitly clears
  `[state+0x66b2]` before the dispatch path begins, and the current exported write-side callers
  we can name after that reset are still just the live-pool preseed `0x00437743`, the sibling
  startup lane `0x00436ad7`, and the editor-side `Industry (Overall)` toggle handler
  `0x004cf430` through `0x00434f20`. So while the fixed `0x6a70..0x73c0` candidate-availability
  block is now well grounded as bundled map/save source data, a direct bulk-import path from that
  block into the live runtime collection `[state+0x66b2]` is still not grounded by the current
  disassembly notes.
  That candidate-side table now has a grounded fixed record layout too: each entry is a `0x22`-byte
  blob with a zero-terminated candidate-name slot at `[entry+0x00..+0x1d]` and one trailing
  availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into
  `[candidate+0x7ac]`. The same scenario state keeps a locomotive-side sibling collection at
  `[state+0x66b6]`, read through `0x00435030` and updated through `0x004350b0`, which is now the
  shared named locomotive-availability lane beneath the `Locomotives` editor page and the
  startup-side locomotive seeding branches. That locomotive-side table is the same pattern at a
  larger width: each entry is a `0x41`-byte blob with a zero-terminated locomotive-name slot at
  `[entry+0x00..+0x3c]` and one trailing availability dword at `[entry+0x3d]`, later mirrored into
  `[loco+0x7b]`. Both override dwords now read most safely as simple availability bits rather than
  wider mode enums. That `319` lane is no longer just a shell-state placeholder: its
  primary grounded work is still the chairman-profile pair
  `world_seed_default_chairman_profile_slots` `0x004377a0` plus
  `world_build_chairman_profile_slot_records` `0x00437220`, which seed the 16 selector bytes at
  `[0x006cec7c+0x87]`, materialize the per-slot chairman records from the scenario selectors,
  campaign override flag `[0x006cec7c+0xc5]`, and the static persona table at `0x005f2d28`, and then
  publish the selected chairman-profile and linked company summary pair through `[state+0x25]` and
  `[state+0x21]`. The local slot-record shape is tighter too because the shell editor panel around
  `0x004cc2d0` now surfaces it directly: `[slot+0x00]` is the staged chairman profile id,
  `[slot+0x01]` is the Optional-versus-Mandatory byte with nonzero=`Optional` and zero=`Mandatory`,
  `[slot+0x02]` combines with the separate per-slot gate at `[world+0x0bc3+slot*9]` to surface
  `Human`, `Computer`, and `Human or Computer`, `[slot+0x03]` is the special occupied-seat byte, and
  `[slot+0x04]` is the numeric tuning field. Both the selector seeder and the record materializer
  treat either `[slot+0x02]` or `[slot+0x03]` as enough to keep a slot live, but current grounded
  writes only seed `[slot+0x03]` on slot zero and later move it solely by whole-record compaction.
  That makes `[slot+0x03]` the strongest current anchor for the distinguished primary-human-seat
  flag rather than a generic role byte. The summary fields are tighter too: current direct accessors
  now show `[state+0x25]` as the selected chairman profile id in `0x006ceb9c`, while `[state+0x21]`
  is the linked owning company id copied from `[profile+0x1dd]` through
  `scenario_state_set_selected_chairman_profile` `0x00434890`. The editor-side scenario setup
  surface beside that chairman panel is clearer now too.
  `map_editor_scenario_metadata_panel_refresh_controls` `0x004ca790` republishes the scenario
  description from `[0x006cec78+0x672e]`, the start-year trio `[+0x66ca]`, `[+0x66d2]`, and
  `[+0x66ce]`, the direct campaign-designated bit `[+0x66de]` through control `0x5b6e`, and the
  inverse of the paired metadata byte `[+0x66f3]` through control `0x5b74`. The resource-side
  anchor is now explicit too: `editorDetail.win` carries localized ids `3160/3161` `Campaign
  Scenario` and `If checked, this map will be reserved as a campaign scenario.` inside the control
  record rooted at `0x5b6e`, so `[+0x66de]` is now the grounded campaign-scenario flag rather than
  an anonymous metadata boolean. `map_editor_scenario_metadata_panel_refresh_briefing_mode`
  `0x004ca670` now bounds the single-player versus multiplayer briefing switch by flipping selector
  `0x621f50`, publishing localized headings `1491` and `3586`, and refreshing the two briefing texts
  from `[state+0x4f30]` and `[+0x5ae9]`. The companion dispatcher
  `map_editor_scenario_metadata_panel_handle_message` `0x004cb4a0` makes the year semantics tighter
  too: it commits the description and both briefing texts from edit-control payloads, toggles the
  same two booleans, and clamps the three year fields to `1829..2100` while maintaining `minimum <=
  default <= maximum`, which now lines up directly with the editor strings `Description:` `Minimum
  Start Year:` `Default Start Year:` `Maximum Start Year:` `Briefing` and `Multi-Player Briefing`.
  The neighboring special-conditions page is clearer as well:
  `map_editor_scenario_special_conditions_panel_construct` `0x004cb2b0` now grounds the live owner
  for the `Setup_Options_Buttons.imb` list rooted at `0xa7fa`, walks the 49-entry static rule table
  at `0x005f3ab0`, counts enabled flags from `[0x006cec78+0x4a7f]`, and publishes the `Special
  Conditions In Effect` summary from localized id `1053`. The same page now has a bounded live
  dispatcher too: `map_editor_scenario_special_conditions_panel_handle_message` `0x004cb8e0` handles
  both bulk selection controls and direct row-state changes, commits them back into
  `[0x006cec78+0x4a7f]`, and then re-enters the panel constructor to refresh the summary. That table
  is no longer just a raw id run; it now clearly includes the finance and construction restrictions
  `2535..2563`, plus later editor toggles such as `Use Bio-Accelerator Cars`, `Disable Cargo
  Economy`, `Disable Train Crashes`, `Disable Train Crashes AND Breakdowns`, and `AI Ignore
  Territories At Startup`. The neighboring available-chairman page is tighter too.
  `map_editor_available_chairman_panel_construct` `0x004ca540` now bounds the shell-side owner for
  the 40-entry persona-availability surface under `0x5aa0..0x5b03`: it walks the same persona table
  family at `0x005f2d28`, publishes one localized chairman-name row per profile, counts enabled
  availability bytes from `[0x006cec78+0x6987..]`, and emits the summary `%1 out of %2 are
  selected.` from localized id `1035`. The live state owner beside it is now grounded as well:
  `map_editor_available_chairman_panel_handle_message` `0x004cb6f0` handles three bulk-selection
  controls `0x5aa1..0x5aa3` by rewriting that same availability-byte array from preset bytes
  embedded in the persona table, and it also commits direct per-row toggle changes from
  `0x5aaa..0x5b03` back into `[state+0x6987..]` before refreshing the page. So the editor lane now
  has three distinct scenario-setup slices rather than one chairman-only blob: chairman slots,
  scenario metadata and briefings, plus both a rule-toggle matrix and an available-chairman pool.
  There is now one adjacent company-side lane too: current neighboring setup flow conditionally
  enters `world_conditionally_seed_named_starting_railroad_companies` `0x0047d440` when the
  Multiplayer preview owner `0x006cd8d8` is absent and either sandbox flag `[0x006cec7c+0x82]` is
  set or shell-state flag `[0x006cec74+0x14c]` is set while editor-map mode `[0x006cec74+0x68]` is
  clear. That helper no longer looks like a generic company refresh. It seeds exactly three fixed
  named railroad-company records from `RT3.lng` ids `575..577`: `Missouri Pacific`, `New York
  Central`, and `Grand Trunk Railroad`. The first seeded company is tied back to the selected
  chairman-profile summary and becomes the selected company id. The second railroad is tighter now
  too: it only receives a chairman link when `profile_collection_count_active_chairman_records`
  finds at least two live chairman records, and the helper then binds the zero-based second active
  chairman through `profile_collection_get_nth_active_chairman_record` with ordinal `1`. The third
  railroad currently gets no matching chairman-link branch in the grounded setup flow and therefore
  remains an unchaired named company in the live roster. The shell UI above that setup lane is now
  tighter as well: `shell_company_list_window_construct` `0x004c7200` builds a live company-list
  window over the company collection at `0x0062be10`, `shell_company_list_window_refresh_rows`
  `0x004c6c30` formats the active companies with localized strings `267..270`, and only then
  conditionally appends one synthetic row id `0x7fff` through
  `shell_company_list_format_company_or_start_row` `0x004c6b40` so `<<Start New Company>>` appears
  as a separate affordance rather than as part of the seeded trio itself. Current shell paging
  around that same roster is tighter too because the live company collection now has a grounded
  active-only ordinal helper family: `company_collection_count_active_companies` `0x00429a50`,
  `company_collection_count_active_companies_before_company_id` `0x004299f0`, and
  `company_collection_get_nth_active_company_id` `0x00429990`. Those helpers now anchor the “current
  company among active companies” math used by shell-side detail and picker flows rather than
  leaving it as anonymous collection glue. `shell_company_list_window_handle_message` `0x004c6f30`
  then routes the synthetic row into `start_new_company_dialog_open` `0x0047d080`, whose commit path
  now grounds through `start_new_company_dialog_commit_create_company` `0x0047d120`. That lower
  helper unlinks any current chairman-owned company, allocates a fresh company id from the live
  collection at `0x0062be10`, initializes it through `0x00428420`, and only then publishes the new
  selected company. The neighboring compact request helper
  `start_new_company_request_create_company` `0x0047d320` does the same fresh-company path from a
  request block and is already reached from the startup-company branch at `0x00470e48`. The
  immediate sibling shell branch below that roster is still station-oriented: current grounded
  resource names and handlers put one branch on `shell_station_detail_window_construct`
  `0x005068c0`, another on `shell_station_list_window_construct` `0x005074c0`, and the subordinate
  selector helper on `shell_station_pick_window_construct` `0x00507620`. But the broader
  company-detail ownership question is no longer open. There is now a separately grounded
  `CompanyDetail.win` family rooted at `shell_company_detail_window_construct` `0x004c5540`, with
  `shell_company_detail_window_handle_message` `0x004c56a0` as its main dispatcher and
  `shell_company_detail_window_refresh_controls` `0x004c2ca0` as the shared repopulation pass for
  the selected-company presentation and tabbed control bands around `0x9476..0x9490`. A grounded
  shell detail-manager caller reaches that constructor at `0x004dde24`, the first finance-action
  layer beneath it is now bounded through `shell_company_detail_issue_bond_offer_flow` `0x004c3890`,
  `shell_company_detail_issue_stock_offer_flow` `0x004c3f30`,
  `shell_company_detail_buyback_stock_flow` `0x004c46d0`, and
  `shell_company_detail_change_dividend_rate_flow` `0x004c5360`, and the first non-finance layer is
  now bounded too through `shell_company_detail_resign_chairmanship_flow` `0x004c5a0e`,
  `shell_company_detail_bankruptcy_flow` `0x004c5b99`, the territory-access family rooted at
  `shell_company_detail_refresh_selected_territory_access_summary` `0x004c1b60` plus
  `shell_company_detail_buy_territory_access_rights_flow` `0x004c5fc9`, backed by
  `company_clear_selected_chairman_if_current_profile` `0x00428a10`,
  `company_declare_bankruptcy_and_halve_bond_debt` `0x00425a90`,
  `company_has_territory_access_rights` `0x00424010`, `company_set_territory_access_rights_byte`
  `0x00424030`, and `company_can_purchase_territory_access_rights` `0x00426be0`, plus the two
  control-transfer lanes. `shell_company_detail_attempt_chairmanship_takeover_flow` `0x0050ccc0` now
  grounds the special chairman's election path: it checks the caller's current stock ownership in
  the target company, rejects insufficient holdings through localized id `623`, rejects recent
  failed attempts through id `624`, and then opens the confirmation under id `625` before seeding
  the local takeover-election state or packaging the same request through the multiplayer shell
  transport. The follow-on resolver `shell_resolve_chairmanship_takeover_vote_and_commit_outcome`
  `0x0050c940` now closes the single-player election loop too: it walks the active chairman profile
  collection, computes weighted votes for and against the takeover, compares the affirmative total
  against half the target-company value, presents the result through
  `shell_present_chairmanship_takeover_vote_outcome_dialog` `0x0050c500` in single-player or
  localized id `3082` in multiplayer, and then either transfers chairmanship through `0x00428a30` or
  stamps the current year into `[company+0x289]` as the grounded takeover-cooldown field.
  `shell_company_detail_attempt_merger_flow` `0x004ec640` now grounds the merger side too: it
  rejects empty worlds through id `727`, rejects recent failed attempts through id `728`, checks the
  proposed premium against company cash through localized id `3889`, and then commits into the
  resolver family. That merger resolver is now bounded too:
  `shell_resolve_merger_vote_and_commit_outcome` `0x004ebd10` walks the active chairman profile
  collection, computes weighted votes for and against the proposed merger, compares the affirmative
  total against half the target-company value, presents the result through
  `shell_present_merger_vote_outcome_dialog` `0x004eb890` in single-player or localized id `3059` in
  multiplayer, and then either commits the merger through `0x00427e20` or stamps the current year
  into `[company+0x15f]` as the grounded merger-cooldown field. The vote-bias side beneath that
  resolver is tighter now too: `scenario_state_compute_issue_opinion_multiplier` `0x00436590` is no
  longer just an abstract issue table lookup because its merger callsite uses issue id `0x3a`, which
  lines up directly with localized id `726` saying merger votes depend on public attitude toward the
  management of the two companies. By contrast the broader support-adjusted share-price helper
  `company_compute_public_support_adjusted_share_price_scalar` `0x00424fd0` uses issue id `0x37`,
  while the finance-side debt helpers now bound `0x38` and `0x39` separately as the explicit
  credit-rating and prime-rate lanes. That leaves `0x37` as the broader investor-confidence lane
  behind equity support, share price, and adjacent governance pressure, with the strongest current
  text anchors coming from the investor-attitude strings `1217` and `3048/3049` about company or
  chairman performance rather than from the merger-only management-attitude term. One older local lead is now ruled out too: the
  `0x460a90` / `0x473620` setup block is the camera-view hotkey family over localized ids
  `3482..3489` (`Select/Assign Camera View 5..8`), not issue-opinion infrastructure, so it should
  no longer be used as evidence for the player-facing meaning of issue `0x37`. The editor-side
  `Stock Prices` label is also no longer being used as direct evidence here: the `0x4ca980` /
  `0x4cadf0` panel owns a separate float-tuning block `[state+0x0bde..0x0bf6]`, with
  `[state+0x0bde]` merely mirroring `[state+0x0be2]`, so that label belongs to a different
  settings family than the issue table behind `0x37`. A direct shell-resource follow-up now narrows
  the remaining caption question too: the extracted `CompanyDetail.win` blob from `rt3_2WIN.PK4`
  contains no plain-English investor or finance caption for this lane, which matches the owner-side
  read that section-0 is a dynamic `0x947f` text widget fed by
  `shell_format_company_governance_and_economy_status_panel` `0x004e5cf0` rather than a separate
  fixed label row. The supporting stat layer is bounded more cleanly now too: the
  surrounding `0x0b` setup in the merger and takeover offer builders is formatter mode rather than a
  player-facing issue number, while the company-side stat wrapper
  `company_read_year_or_control_transfer_metric_value` `0x0042a5d0` now reads as a generic
  stat-family accessor over year-relative series or the bounded slot family in
  `company_read_control_transfer_metric_slot` `0x0042a2e0`. Its recurring family token `0x2329` is
  no longer treated as an issue id here either; it is the stat-family selector paired with localized
  company-stat label id `2329`. That means the paired raw and scaled helpers at `0x004241e0` and
  `0x00424200` now read as narrow control-transfer offer policy totals instead of direct
  issue-argument consumers, and the same broader support-and-governance metric family now also feeds
  the annual shareholder-revolt and creditor-liquidation lane surfaced by localized ids `300..304`.
  The editor-side help text cluster around ids `2433..2437` is no longer floating either: current
  grounded map-editor code now has a live economic tuning family beside the chairman-slot panel.
  `map_editor_economic_cost_slider_panel_construct` `0x004cadf0` binds six slider controls through
  `map_editor_economic_cost_slider_dispatch` `0x004ca980` into the scenario-state float block
  `[0x006cec78+0x0be2..0x0bf6]`, while the surrounding descriptor table at `0x00611c70..0x00612220`
  pairs that wider editor lane with localized fields `Prime Rate`, `Merger Premium`, and `Build
  Stations Cost` through `Steam Engine Cost` plus the comparison or help texts `2433..2437`. The
  broader shell-state master flag at `[0x006cec74+0x68]` still sits above the remaining post-load
  phases, plus two narrower per-phase gates: `[0x006cec74+0x174]` directly fronts id `320` `Setting
  Up Buildings...` and the later region-owned structure-demand and placement pass through
  `world_region_collection_run_building_population_pass` `0x00421c20` plus the deeper per-region
  worker `world_region_balance_structure_demand_and_place_candidates` `0x004235c0`, while
  `[0x006cec74+0x178]` directly fronts id `321` `Seeding Economy...` and the chunked burst helper
  `simulation_run_chunked_fast_forward_burst`, whose grounded tail now also sweeps the live region
  collection through `world_region_refresh_cached_category_totals_and_weight_slots` `0x00423d30`;
  id `322` then fronts `Calculating Heights...`. The
  master `+0x68` flag is no longer just structural: the shell load/save coordinators now use the
  same flag to force the editor-map `.gmp` family, so current evidence treats it as the broader
  editor-map mode above those later setup branches rather than an unnamed generic toggle. That
  worker is no longer one opaque building bucket: current grounded categories split into `House`, a
  weighted region-profile family surfaced through the `Industry Weightings` stats path, and a third
  branch whose low-level fallback token is `Commercial` but whose aligned stats label is `City
  Support`. The same placement-commit gate beneath it, `world_region_validate_and_commit_candidate_placement`
  `0x00422a70`, is also corroborated by the separate world-side randomized batch helper
  `world_try_place_random_structure_batch_from_compact_record` `0x00430270`, which retries
  placements around one compact center/radius record rather than the ordinary per-region demand
  deficits. That batch placer now sits under a wider compact runtime-effect dispatcher,
  `world_apply_compact_runtime_effect_record_to_resolved_targets` `0x00431b20`, so the world-side
  branch is no longer just “another caller near `0x43051e`” but one real effect family alongside
  the ordinary region-demand worker. Above that, the live scenario event collection at `0x0062be18`
  now has a tighter runtime-effect lane too: `scenario_runtime_effect_record_service_and_dispatch_linked_compact_effects`
  `0x004323a0` services one live runtime-effect record, dispatches its linked compact effects
  through `0x00431b20`, and can synthesize follow-on records through
  `scenario_runtime_effect_record_build_followon_effect_from_compact_record_and_targets`
  `0x00430b50`, which in turn allocates new live records through
  `scenario_event_collection_allocate_runtime_effect_record_from_compact_payload` `0x00432ea0`.
  Above that, `scenario_event_collection_service_runtime_effect_records_for_trigger_kind`
  `0x00432f40` now bounds the collection-wide loop that services those live runtime-effect records
  for one trigger kind. That trigger split is tighter now too: recurring simulation maintenance
  drives kinds `1`, `0`, `3`, and `2`; the neighboring route-style follow-on drives `5` and `4`;
  startup-company and named-railroad creation branches drive `7`; kind `6` is now bounded as a
  mixed post-change family spanning the placed-structure post-create tail, one build-version-gated
  company-startup or roster-refresh tail, and the route-entry post-change sweep on `0x006cfca8`;
  one world-entry-side one-shot gate drives `8` and then clears shell-profile latch
  `[0x006cec7c+0x97]`; the briefing-text query lane is kind `9`; and the collection dirty latch
  still forces the internal rerun at kind `0x0a`.
  That moves this branch out of the “isolated world-side placement oddity” bucket and into a real
  scenario-runtime effect pipeline with a mostly bounded trigger-kind family.
  The same lower helper also reappears later on a slower
  simulation-side cadence with
  scale `1/12`, so it no longer looks like one-time setup glue only. The actual game-speed control
  family remains separate, rooted at `world_set_game_speed_mode` `0x00434680`,
  `world_adjust_game_speed_mode_delta` `0x00434850`, and `world_toggle_pause_or_restore_game_speed`
  `0x00437a60`.
- CompanyDetail addendum: the shared helper `shell_company_detail_resolve_selected_company` at
  `0x004c16f0` now bounds the common current-company accessor beneath the whole pane, and the
  read-side owner also has a separate active-company navigation family through
  `shell_company_detail_step_selected_active_company_delta` at `0x004c3470` plus the next or
  previous wrappers at `0x004c3540` and `0x004c3550`. The section switch in
  `shell_company_detail_window_refresh_controls` is now grounded too: section index `0x006cfe60`
  selects a chairman/governance slice, a debt-and-capital slice, a per-share slice, or a
  territory-access slice, published through the tab band around `0x9472..0x9479`, with adjacent
  section-navigation controls around `0x947b..0x947c` and `0x948f..0x9490`.
- Key Dispatchers: `shell_controller_window_message_dispatch`,
  `shell_input_apply_window_key_transition`, `shell_input_snapshot_dispatch_state`,
  `shell_input_cursor_inside_active_view`, `world_load_saved_runtime_state_bundle`,
  `world_runtime_serialize_smp_bundle`, `simulation_frame_accumulate_and_step_world`,
  `game_message_window_service_if_present`, `game_message_window_service_frame`,
  `game_uppermost_window_handle_message`, `game_uppermost_window_service_world_hotspot_band`,
  `game_uppermost_window_refresh_controls`,
  `world_view_service_keyboard_turn_pan_and_zoom_bindings`, `world_view_step_heading_quadrant`,
  `world_view_step_zoom_bucket`, `world_seed_default_chairman_profile_slots`,
  `world_build_chairman_profile_slot_records`,
  `world_conditionally_seed_named_starting_railroad_companies`,
  `scenario_state_set_selected_chairman_profile`,
  `scenario_state_get_selected_chairman_profile_record`,
  `scenario_state_get_selected_chairman_company_record`, `shell_company_list_window_construct`,
  `shell_company_list_window_refresh_rows`, `shell_company_list_window_handle_message`,
  `start_new_company_dialog_open`, `start_new_company_dialog_commit_create_company`,
  `start_new_company_request_create_company`, `shell_station_detail_window_construct`,
  `shell_station_list_window_construct`, `shell_station_list_window_handle_message`,
  `shell_station_pick_window_construct`, `shell_station_pick_window_populate_station_rows`,
  `map_editor_chairman_slot_panel_construct`, `map_editor_chairman_slot_panel_handle_message`,
  `map_editor_chairman_slot_panel_refresh_selected_slot`,
  `map_editor_chairman_slot_panel_cycle_selected_slot_profile`,
  `map_editor_available_chairman_panel_construct`,
  `map_editor_available_chairman_panel_handle_message`,
  `map_editor_scenario_metadata_panel_refresh_briefing_mode`,
  `map_editor_scenario_metadata_panel_refresh_controls`,
  `map_editor_scenario_metadata_panel_handle_message`,
  `map_editor_scenario_special_conditions_panel_construct`,
  `map_editor_scenario_special_conditions_panel_handle_message`,
  `map_editor_economic_cost_slider_panel_construct`, `map_editor_economic_cost_slider_dispatch`,
  `station_place_world_surface_sync_and_dispatch`, `station_place_window_handle_message`,
  `track_lay_window_refresh_controls`, `track_lay_window_service_frame`,
  `track_lay_window_handle_message`, `simulation_advance_to_target_calendar_point`, the smaller
  single-step helper at `0x00409e80`, `0x0040a9c0`, `0x0040a910`, and
  `simulation_service_periodic_boundary_work`.
- State Anchors: shell input object `0x006d4018`, per-key state table starting at `[input+0x100]`,
  packed shell input flags at `[input+0xa8c]` now grounded as Right Shift `0x1`, Left Shift `0x2`,
  Control `0x4`, and Alt `0x20`, nested dispatch counter `[input+0xa90]`, global shell controller
  `0x006d4024`, active world root `0x0062c120`, `GameMessage.win` object `0x006d081c`,
  `GameUppermost.win` overlay object `0x006d0820`, `StationPlace.win` tool object `0x006d1720`,
  `TrackLay.win` tool object `0x006d1a8c`, accumulated leftover simulation time at `[this+0x4c80]`,
  shell and mode globals at `0x006cec74`, `0x006cec78`, and `0x006cec7c`, world manager collections
  at `0x0062be10`, `0x006ceb9c`, `0x006cfcbc`, `0x006cec20`, `0x0062bae0`, and `0x006acd34`, plus
  the packed calendar-like tuple fields around `[this+0x0d]`, `[this+0x0f]`, `[this+0x11]`, and
  `[this+0x14]`.
- Subsystem Handoffs: the controller window dispatcher now looks like the first grounded input
  ingress. It translates keyboard and mouse `WM_*` traffic into shell controller state and the
  separate input object at `0x006d4018`; read-side cursor and camera helpers later snapshot that
  object through `shell_input_snapshot_dispatch_state` and gate world-relative interaction through
  `shell_input_cursor_inside_active_view`. Current grounded consumers around `0x00478cb0`,
  `0x004e0780`, `0x0053f450`, and `0x0053fe90` still sit on the shell controller path and consult
  `0x006d4024` or the world owner at `0x0062be68`, so there is still no evidence for a distinct
  gameplay-only input object after world entry. Instead, the first deeper world-mode interaction
  branch now looks like a shared world-view coordinator layered on top of the same shell-fed input
  state. Shell_transition_mode ensures the `GameUppermost.win` object at `0x006d0820`; its message
  dispatcher `game_uppermost_window_handle_message` owns the narrow action band `0x7918` through
  `0x7921`; and the recurring service helper `game_uppermost_window_service_world_hotspot_band`
  rate-limits those hotspot actions, rechecks `shell_input_cursor_inside_active_view`, and then pans
  the live world view through `world_view_pan_relative_offset_in_camera_plane` `0x0043d130`. The
  same lower setter family is also reached from the cursor-drag path through
  `world_view_apply_screen_delta_to_focus_position` `0x0043d0c0`. Above both of those sits the
  larger recurring service `world_view_service_shell_input_pan_and_hover` `0x0043db00`, which now
  has one grounded keyboard branch beneath it:
  `world_view_service_keyboard_turn_pan_and_zoom_bindings` `0x0043d740`. That helper resolves four
  binding-pair families from the shell input table via `0x0054e7d0`, and the localized labels are
  now grounded from `Data/Language/RT3.lng`: `Camera Forward` and `Camera Backward` feed the first
  signed pan channel, `Camera Left` and `Camera Right` feed the second signed pan channel, `Camera
  Zoom In` and `Camera Zoom Out` feed the signed zoom-step channel that `0x0043db00` smooths into
  `world_view_step_zoom_bucket` `0x0043cc30`, and `Camera Rotate Left` plus `Camera Rotate Right`
  feed the continuous heading-turn branch through `0x0043c810`. The setup side is now better bounded
  too: `world_view_seed_keyboard_binding_slot_pairs` at `0x00439e40` seeds the eight slot pairs at
  `[this+0x0a6]` through `[this+0x0e2]` from the global action-binding registry through `0x0045f370`
  using the distinct registry keys `0x0043d2a0` through `0x0043d310`, and the registration block at
  `0x00460769` through `0x004608e7` shows those roots are defaulted to the expected Up Down Left and
  Right virtual keys before runtime polling begins. Beneath that camera stack, the enclosing frame
  path now has one grounded non-view sidecar: after `0x0043db00` it reads the active controller-view
  object pointer at `[0x006d4024+0x18]+0x366e`, compares it against the latched target at
  `[frame_owner+0x66a2]`, fires exit and enter-style vtable callbacks on pointer changes through
  slots `+0x64` and `+0x60`, and only latches the new object when the object passes its own slot
  `+0x1c` availability test and shell detail control id `0x07d6` on `0x006d0818` has flag bit `0x4`.
  That `0x07d6` gate is now more bounded than before: the dedicated `TrackLay.win` tool family
  rooted at `0x006d1a8c` special-cases the same control id in both `track_lay_window_service_frame`
  and `track_lay_window_handle_message`, uses world hit tests through `0x00448ac0` to arm and
  release a drag latch on that surface, and routes the resulting command work through the shared
  track-lay mode state at `0x00622b0c`. The surrounding `track_lay_window_refresh_controls` pass now
  shows that this is not just one isolated drag handler: the same tool family owns three mutually
  exclusive primary mode buttons at `0x985e` `0x985f` and `0x9860`, and current primary evidence now
  bounds those values as `Lay single track.` `0x1`, `Lay double track.` `0x4`, and `Bulldoze` `0x40`
  from the localized strings 2054 2055 and 1721 plus the matching control-routing branches in
  `track_lay_window_handle_message`. The same family also owns the downstream route-entry policy
  bridge at `0x004955b0`: current caller evidence says that helper maps the live TrackLay primary
  mode into endpoint-synthesis policy `1` or `4` before the tool re-enters `0x00493cf0`, which is
  the strongest current bridge from the player-facing single-track versus double-track buttons into
  the lower route-builder policy bytes. The same family also owns a bridge-type preference selector
  rooted at `0x006cec74+0x138`, two wrapped `Never` through `Common` frequency settings at
  `0x006cec74+0x140` and `0x006cec74+0x13c`, two boolean track-lay preference toggles, and the
  electrify-all-track action path. Those last two toggles are now tighter than before: current
  evidence strongly aligns control `0x986e` and state `0x006cec74+0x144` with `Auto-Hide Trees
  During Track Lay` from strings 1838 and 1839, while control `0x986d` and state `0x006cec78+0x4c74`
  align with `Auto-Show Grade During Track Lay` from strings 3904 and 3905. That mapping is still
  evidence-backed rather than absolutely direct from a recovered resource table, but the state
  ownership and control order now make it the strongest current fit. That makes `0x07d6` look like
  the shared main-world interaction surface inside a broader TrackLay world-command subsystem, not
  an unrelated detail button. The neighboring `StationPlace.win` family is now grounded on that same
  surface too: the shell detail-panel constructor family allocates it through
  `station_place_window_construct` at `0x00509d80`, publishes it at `0x006d1720`, services it each
  frame through `station_place_window_service_frame` at `0x0050a530`, and routes player-facing
  commands through `station_place_window_handle_message` at `0x005091b0`. That dispatcher
  special-cases the same `0x07d6` control, and the shared helper
  `station_place_world_surface_sync_and_dispatch` at `0x00508bb0` either accepts that direct surface
  traffic or falls back to the same detail-panel control looked up through `0x006d0818`, rechecks
  flag bit `0x4`, hit-tests the world through `0x00448ac0`, stages world coordinates into
  `0x006d1738` and `0x006d173c`, refreshes the selected-site summary through
  `station_place_format_selected_site_summary`, and updates the live station-placement selection
  state at `0x00622af0`, `0x00622aec`, and `0x006d1740`. The category side of that state is now
  tighter too: the shared helper `0x0044bd10` quantizes the staged world coordinates into the
  current cell, resolves the mixed byte-or-word region id from `[world+0x212d]`, looks up the
  owning city-or-region entry through `0x0062bae0`, and returns `[entry+0x272]` with fallback
  `5`; the StationPlace world-surface branches at `0x00508b80`, `0x00508d59`, and `0x0050a4e6`
  use that result directly to refresh the current selection category latch at `0x00622af0`.
  Together with
  `station_place_select_category_and_refresh` `0x00508880`,
  `station_place_refresh_category_controls` `0x00507b90`, and `station_place_format_preview_panel`
  `0x00508730`, that makes StationPlace a second grounded consumer of the shared main-world
  interaction surface rather than only a sibling constructor plus frame hook. The StationPlace
  control semantics are now tighter too: the top category strip at `0x697c` through `0x6981` now
  grounds as small station, medium station, large station, service tower, maintenance facility, and
  non-station building from `RT3.lng` strings 2197 through 2202. For the three station categories
  only, the secondary strip at `0x6988` and `0x6989` plus display field `0x698c` no longer looks
  like another placement mode family; it is a building-style scroller. The click handlers on
  `0x6988` and `0x6989` cycle the style override in `0x00622aec`, and the display path builds the
  active style token from `StationSml`, `StationMed`, or `StationLrg` plus the localized
  architecture styles `Victorian`, `Tudor`, `Southwest`, `Persian`, `Kyoto`, and `Clapboard` from
  `RT3.lng` ids 2672 through 2667. One layer lower, the remaining opaque controls are now much
  tighter: `0x6985` and `0x6986` are no longer a generic assist toggle but the two station-rotation
  policy choices from strings 2207 and 2206, switching between auto-orienting the building to track
  or obstacles and strictly obeying the rotation specified by the circle above. The dedicated
  control at `0x6987` is the station-rotation circle itself, wired through callback `0x00507a90` and
  aligned with `Click to rotate the building. You can also use bracket keys [ and ] to rotate
  buildings.` string 2208. That matches the lower behavior too: when the strict-rotation choice is
  off, both preview and commit paths route staged coordinates through `0x00508040`, which performs
  the extra orientation search before validation; when strict rotation is on, that pass is skipped
  and the current angle in `0x006d172c` is used directly. The direct shell UI also exposes the same
  discrete view-step family through `world_view_step_heading_quadrant` `0x0043cb00` and
  `world_view_step_zoom_bucket` `0x0043cc30`. The neighboring gating predicates
  `world_view_should_drive_primary_pan_channel` and `world_view_should_drive_secondary_pan_channel`
  test packed shell input bits `0x3`, and `shell_input_apply_window_key_transition` now grounds
  those bits as the left and right Shift modifiers from scan codes `0x2a` and `0x36`. That means
  cursor drag, overlay hotspots, held Shift state, direct keyboard turn/pan/zoom bindings, the
  TrackLay and StationPlace world-command surfaces, and at least one frame-owned hover or
  focus-target branch all converge under the same shell-fed world-mode input path rather than a
  separate gameplay-input stack.
- Evidence: function-map rows for `shell_controller_window_message_dispatch`,
  `shell_drain_pending_window_messages`, `shell_input_state_init`,
  `shell_input_apply_window_key_transition`, `shell_input_snapshot_dispatch_state`,
  `shell_input_cursor_inside_active_view`, `world_load_saved_runtime_state_bundle`,
  `world_runtime_serialize_smp_bundle`, `world_entry_transition_and_runtime_bringup`,
  `simulation_frame_accumulate_and_step_world`, `game_message_window_service_if_present`,
  `game_message_window_service_frame`, `shell_ensure_game_uppermost_window`,
  `game_uppermost_window_construct`, `game_uppermost_window_handle_message`,
  `game_uppermost_window_service_world_hotspot_band`, `world_view_set_focus_position_xyz`,
  `world_view_apply_screen_delta_to_focus_position`,
  `world_view_pan_relative_offset_in_camera_plane`, `world_view_seed_keyboard_binding_slot_pairs`,
  `world_view_service_keyboard_turn_pan_and_zoom_bindings`, `world_view_step_heading_quadrant`,
  `world_view_step_zoom_bucket`, `world_view_should_drive_primary_pan_channel`,
  `world_view_should_drive_secondary_pan_channel`, `world_view_service_shell_input_pan_and_hover`,
  `world_seed_default_chairman_profile_slots`, `world_build_chairman_profile_slot_records`,
  `world_conditionally_seed_named_starting_railroad_companies`,
  `profile_collection_count_active_chairman_records`,
  `profile_collection_get_nth_active_chairman_record`,
  `scenario_state_set_selected_chairman_profile`,
  `scenario_state_get_selected_chairman_profile_record`,
  `scenario_state_get_selected_chairman_company_record`, `start_new_company_dialog_open`,
  `start_new_company_dialog_commit_create_company`, `start_new_company_request_create_company`,
  `shell_company_list_format_company_or_start_row`,
  `shell_company_list_activate_or_shift_center_company`, `shell_company_list_window_refresh_rows`,
  `shell_company_list_window_handle_message`, `shell_company_list_window_construct`,
  `shell_company_detail_window_refresh_controls`, `shell_company_detail_window_construct`,
  `shell_company_detail_window_handle_message`, `shell_station_detail_window_construct`,
  `shell_station_list_window_construct`, `shell_station_list_window_handle_message`,
  `shell_station_pick_window_construct`, `shell_station_pick_window_populate_station_rows`,
  `map_editor_chairman_slot_panel_construct`, `map_editor_chairman_slot_panel_refresh_slot_list`,
  `map_editor_chairman_slot_panel_refresh_selected_slot`,
  `map_editor_chairman_slot_panel_refresh_slot_counters`,
  `map_editor_chairman_slot_panel_cycle_selected_slot_profile`,
  `map_editor_chairman_slot_panel_handle_message`, `map_editor_available_chairman_panel_construct`,
  `map_editor_available_chairman_panel_handle_message`,
  `map_editor_scenario_metadata_panel_refresh_briefing_mode`,
  `map_editor_scenario_metadata_panel_refresh_controls`,
  `map_editor_scenario_metadata_panel_handle_message`,
  `map_editor_scenario_special_conditions_panel_construct`,
  `map_editor_scenario_special_conditions_panel_handle_message`,
  `map_editor_economic_cost_slider_panel_construct`, `map_editor_economic_cost_slider_dispatch`,
  `station_place_refresh_category_controls`, `station_place_format_selected_site_summary`,
  `station_place_format_preview_panel`, `station_place_select_category_and_refresh`,
  `station_place_world_surface_sync_and_dispatch`, `station_place_window_handle_message`,
  `station_place_window_construct`, `station_place_window_service_frame`,
  `track_lay_window_refresh_controls`, `track_lay_window_construct`,
  `track_lay_window_service_frame`, `track_lay_window_handle_message`, and
  `simulation_service_periodic_boundary_work`, plus the shell-input disassembly around `0x0054f290`,
  the world-view setup and service branches around `0x00439e40`, `0x0043d740`, `0x0043db00`,
  `0x0043cb00`, and `0x0043cc30`, the `319` setup-side branches around `0x004377a0`, `0x00437220`,
  `0x00477820`, `0x00477860`, `0x0047d440`, `0x004c6c30`, `0x004c6f30`, `0x0047d080`, `0x0047d120`,
  `0x0047d320`, `0x004c2ca0`, `0x004c5540`, `0x004c56a0`, `0x005068c0`, `0x005071e0`, `0x005074c0`,
  and `0x005076c0`, the direct summary-field helpers around `0x00434870` `0x00434890` and
  `0x004348c0`, the company-link writers at `0x00427c70` and `0x00427d74`, the company constructor
  at `0x00428420`, the startup-company branch around `0x00470e48`, the shell company-list strings
  `266` `<<Start New Company>>`, `267` `You are the chairman of the %1!`, `268` `The %1 has no
  chairman at the moment.`, `269` `%1 is the chairman of the %2.`, `270` `Double-click for
  details.`, and `2992` `Shift-Click to center on this company's primary station.`, the
  `CompanyDetail.imb` and `CompanyDetail.win` resource strings in `.rdata`, the `StationDetail.imb`,
  `StationDetail.win`, `StationList.win`, and `StationPick.win` resource strings in `.rdata`, the
  shell editor window branches around `0x004c9da0`, `0x004ca010`, `0x004ca1c0`, `0x004ca540`,
  `0x004ca670`, `0x004ca790`, `0x004ca980`, `0x004cb2b0`, `0x004cb4a0`, `0x004cb6f0`, `0x004cb8e0`,
  `0x004cc250`, `0x004cc2d0`, `0x004ceb90`, and `0x004cecc0`, the localized chairman-slot strings
  `2997` through `3001` `Optional` `Mandatory` `Human or Computer` `Computer` and `Human`, the
  localized scenario-editor strings `1483..1492` `Description:` through `Type the briefing for this
  map.`, the localized summary strings `1035` `%1 out of %2 are selected.` and `1053` `Special
  Conditions In Effect`, the 40-entry persona availability page under `0x5aa0..0x5b03`, the 36-entry
  special-condition table at `0x005f3ab0` covering ids `2535..2563`, `2874`, `3722`, `3835`, `3850`,
  `3852`, and `3920`, the static persona table at `0x005f2d28`, the selector array at
  `0x006cec7c+0x87`, the persona collection at `0x006ceb9c`, the localized persona strings in
  `Data/Language/RT3.lng` including `2730` `Unassigned`, the named-chairman range `2731+`, and the
  neighboring biography range `2495+`, plus the seeded railroad-name strings `575` `Missouri
  Pacific`, `576` `New York Central`, and `577` `Grand Trunk Railroad`, the StationPlace.win
  constructor plus category, dispatcher, rotation-circle, shared-world-surface, preview-build, and
  recurring service branches around `0x00507a90`, `0x00507b90`, `0x00508550`, `0x00508730`,
  `0x00508880`, `0x00508bb0`, `0x005091b0`, `0x00509d80`, and `0x0050a530`, the StationPlace string
  cluster `Place a small station` 2197 `Place a medium station` 2198 `Place a large station` 2199
  `Place a service tower` 2200 `Place a maintenance facility` 2201 `Place a non-station building`
  2202 `Scroll through building styles.` 2203 `When placing the building, it will strictly adhere to
  the rotation specified by the circle above.` 2206 `When placing the building, it will rotate
  itself as needed to orient to track or avoid obstacles.` 2207 `Click to rotate the building. You
  can also use bracket keys [ and ] to rotate buildings.` 2208 and the architecture-style labels
  `Clapboard` 2667 `Kyoto` 2668 `Persian` 2669 `Southwest` 2670 `Tudor` 2671 and `Victorian` 2672,
  the TrackLay.win constructor and dispatcher family around `0x0050d2d0`, `0x0050e400`,
  `0x0050e1e0`, and `0x0050e5c0`, the localized `Never` through `Common` strings 615 through 618,
  the track-lay strings `Bulldoze` 1721 `Lay single track.` 2054 `Lay double track.` 2055 and 3114,
  and the deeper shared bulldoze helper at `0x0044b160`. That helper is no longer just a vague
  proximity scan: it validates the active company unless editor mode is active, emits the exact
  RT3.lng bulldoze rejection ladder `419..424`, reads company cash through `0x0042a5d0`,
  debits approved bulldoze cost through `0x0042a080`, and then scans nearby route entries,
  linked structures, city-or-region records, route blockers, and placed structures before
  dispatching the selected delete branch through `0x004937f0`, `0x004941a0`, `0x0048abf0`, or the
  surrounding placed-structure virtual slot `+0x58`. That makes the TrackLay `Bulldoze` mode
  tighter than before: the tool-side mode latch at `0x00622b0c == 0x40` is only the front-end
  selector, while the actual world-side bulldoze choice and failure policy sits under `0x0044b160`
  and is reused by neighboring world-surface callers beyond TrackLay itself.
  the TrackLay preference strings `Auto-Hide Trees During Track Lay` 1838 `If 'Auto-Hide Trees
  During Track Lay' is checked, trees will automatically be reduced to small stumps whenever you are
  in track laying mode.` 1839 `Auto-Show Grade During Track Lay` 3904 and `If 'Auto-Show Grade
  During Track Lay' is checked, you'll see the grade number over the track while laying track -
  useful for trying to keep your slopes to a minimum.` 3905, the electrify-all confirmation and
  failure strings 3083 3084 3837 and 3900, the binding-registry lookup path at `0x0045f370`, the
  registration block at `0x00460769` through `0x004608e7`, and the localized labels in
  `Data/Language/RT3.lng` ids `3466` through `3473`.
- Open Questions: current evidence grounds the shell-controller-backed input and frame path as the
  only coordinator after world entry; no separate outer gameplay loop or gameplay-only input
  object is grounded yet. The new setup-pipeline evidence also points the same way: the
  currently grounded chunked burst path at `0x00437b20` now looks subordinate to
  `world_run_post_load_generation_pipeline` rather than to the ordinary speed controls, and even
  there it still reuses the same lower stepper and pumps shell work between chunks instead of
  revealing a detached gameplay loop owner. The player-facing speed-control family is now cleaner
  too: `world_set_game_speed_mode` owns the bounded `Paused` through `Very Fast` ladder plus the
  hidden `Ultra Fast 6..9` extension, `world_toggle_pause_or_restore_game_speed` uses `[this+0x1d]`
  as the resume slot, and the multiplayer host restriction now looks attached to that same setter
  family rather than to the setup-side burst helper. The frame-owned shell coupling is tighter now
  too: inside `simulation_frame_accumulate_and_step_world` itself, one direct branch opens or
  focuses `LoadScreen.win` through `shell_open_or_focus_load_screen_page`, and the post-step
  shell-window ladder also probes several sibling shell windows by the same presence-plus-dirty
  pattern, including the live `LoadScreen` singleton, the shared callback-driven custom modal, the
  shared file-options dialog, `SettingsWindow.win`, the now-grounded `Overview.win` and
  `BuildingDetail.win` singletons, the adjacent tool-window strip now grounded as
  `Bulldoze.win`, `ChangeHeight.win`, `ChangeTrees.win`, `PaintRegion.win`, `PaintSound.win`,
  `PaintTerrain.win`, `PaintTerritory.win`, and `StockBuy.win`, and now the shell-side
  `Trainbuy.win` singleton too. That
  train-buy family is no longer just an unnamed probe pair either: the opener path is now grounded
  under the same shell-owned cadence through `shell_can_open_trainbuy_window_or_warn` and
  `shell_open_or_focus_trainbuy_window`, and its current family semantics already extend beyond a
  bare locomotive picker into selected-train upgrade summary and route-edit affordances. The
  selected-train side is tighter now too: we have explicit query helpers for the selected train
  record, id, validity, and company ownership, plus one explicit ownership-mismatch warning modal.
  That same pass also clarified one boundary we should not conflate: the neighboring shell family
  rooted at `0x006d3b20` is now grounded separately as `TrainDetail.win`. It reuses the same
  selected-train context and some of the same helpers, but it is not the same `Trainbuy.win`
  singleton family. The `TrainDetail.win` side now has its own constructor, opener, refresh path,
  and message owner above the broader train-command strip. Its inner `0xcb` strip is tighter now
  too: one bounded branch is the selected-train engine-replacement or trainbuy handoff lane using
  warning ids `593/594`, and another is the selected-train retirement lane using `595/596/597`
  with either a local teardown path or multiplayer opcode `0x37`. The remaining train-command
  family is narrower too: the shared `0x33`-stride helper trio at `0x004b2f00`, `0x004b3000`, and
  `0x004b3160` now looks like a real train route-stop or waypoint list rather than a generic row
  buffer, and route-entry flag byte `+0x28` now has one grounded top-level split: sign bit clear
  entries are the live placed-structure-backed family, while sign bit set entries use the direct
  route-node payload side. The helper `train_route_list_count_live_site_reference_entries`
  `0x004b2b80` now counts the first family explicitly. One deeper lower-bit result is grounded too:
  both `train_route_list_insert_staged_entry_at_index` and the auxiliary finalize helper
  `train_finalize_aux_route_entry_buffer_preserving_subflags` `0x004a94b0` explicitly preserve
  bits `0x40`, `0x20`, and `0x10` in the same flag byte during route-entry rewrites. Those bits are
  also no longer copy-only: the neighboring shell helper
  `shell_building_detail_refresh_flagged_service_capability_rows` `0x004b9a20` now consumes them to
  restyle the `BuildingDetail.win` row bands `0x7d07..0x7d1c` and `0x7f58..0x801f`. The exact
  player-facing labels for those rows are still open, but the subflags now have one real shell-side
  consumer instead of only preservation logic. The broader `BuildingDetail.win` refresh family is
  tighter too: `shell_building_detail_refresh_subject_cargo_and_service_rows` `0x004ba3d0` now
  clearly owns the selected subject rows around `0x7d06`, `0x7d96..`, and `0x7d0e`, resolving
  ordinary ids through the live candidate collection and the special express-side ids through the
  embedded `AnyCargo.imb`, `AnyFreight.imb`, and `PassMail.imb` paths. The first fixed triplet is
  now table-grounded instead of only inferred: `0x00621df8` seeds the short-label controls
  `0x7dc8..0x7dca` with RT3.lng `494..496` `Any Cargo`, `Any Freight`, and `Any Express`, while
  `0x00621e10` seeds the adjacent `0x7e90..0x7e92` icon-name triplet with `AnyCargo`,
  `AnyFreight`, and `PassMail` before `%1.imb` formatting. RT3.lng also tightens the longer popup
  side now: `0x00621e04` feeds the first clickable selector triplet `0x7f58..0x7f5a` with
  `494/497/498`, so the help text there is `Any Cargo`, `Any Freight\n(Freight is everything but
  Passengers, Mail, and Troops)`, and `Any Express\n(Express is Passengers, Mail, and Troops)`.
  The sibling special service rows still align to `Dining Car` and `Caboose`. The extracted
  `BuildingDetail.win` blob now sharpens the resource boundary too: its embedded text table is
  currently sparse rather than rich, exposing the help line for `0x7d01`, repeated
  `BuildingDetail.imb` asset strings, and one standalone caption entry `Cargo`. That makes
  `Cargo` the strongest current resource-side anchor for the row header around `0x7d06`. The
  ordinary deeper rows are tighter now too: they do not look like hidden caption-table entries,
  but like live candidate-derived rows. The current path validates each ordinary id through
  `indexed_collection_entry_id_is_live` `0x00517d40`, resolves the concrete candidate record
  through `indexed_collection_resolve_live_entry_by_id` `0x00518140`, and then reuses candidate
  field `[record+0x04]` as one shared stem for both the row asset `%s.imb` path and the
  neighboring display-label lookup through
  `localization_lookup_display_label_by_stem_or_fallback` `0x0051c920`. That lookup is now
  bounded too: it scans the static stem table at `0x006243c8`, already grounding entries such as
  `Alcohol`, `Aluminum Mill`, `Automobiles`, `Bauxite`, and `Big Boy` against RT3.lng
  `3202..3220`, and only falls back to localized id `3866` when no table entry matches before the
  fixed `0x384..0x386` express-side triplet takes over. One neighboring candidate-side helper is
  tighter now too: `structure_candidate_query_route_style_or_local_availability_metric`
  `0x0041e650` shares the same route-style byte at `[candidate+0x46]`, returning the cached local
  float at `[candidate+0x5a]` for ordinary candidates but switching route-style rows to one
  normalized count over the world-side route-link collection `0x006ada90` keyed by candidate class
  `[candidate+0x3e]`. That collection is tighter now too: it is constructed during world bring-up
  by `placed_structure_route_link_collection_construct` `0x00468110`, and current grounded
  creation flow through `placed_structure_route_link_allocate_site_pair_for_candidate_class`
  `0x00467f50` seeds class byte `+0x10`, a masked initial state template, and the strongest
  current creation-side site-pair fields at `+0x0c` and `+0x0e` before
  `placed_structure_route_link_attach_site_owner` `0x00467eb0` links the new route-link record
  into the placed-structure-owned chain at `[site+0x272]`. The owner-side split is tighter now
  too: route-link field `+0x08` is the separate route-node-style owner anchor used by
  `placed_structure_route_link_attach_route_node_owner` `0x00467f20`, while `+0x0a/+0x0c/+0x0e`
  now read as the site-reference triple matched by
  `placed_structure_route_link_collection_remove_links_touching_site_id` `0x004681f0`. Creation
  flow now sharpens that further: `+0x0c` is the strongest current candidate for the stable
  first-site field seeded before owner attachment, `+0x0a` is the mutable owner-site anchor
  installed by the attach helper, and `+0x0e` is the stable second-site field. One more split is
  tighter now too: `placed_structure_route_link_recompute_endpoint_pair_state` `0x00467c30`
  currently uses `+0x0a` and `+0x0e` as the active endpoint site pair while recomputing state
  byte `+0x12`; `+0x0c` is still not directly read there. The family also has a clearer release
  and refresh side now: `placed_structure_route_link_release_and_detach` `0x004680b0` rolls back
  the class counters and then tails into `placed_structure_route_link_detach_current_owner_chain`
  `0x00467df0`, while
  `placed_structure_route_link_collection_recompute_all_endpoint_pair_state` `0x004682c0`
  explicitly reruns the per-record endpoint-pair reconciler across the whole live route-link
  collection. One layer above that,
  `placed_structure_route_link_rebuild_route_style_grid_counters_and_endpoint_state`
  `0x00468300` now looks like the full-family refresh owner: it clears three route-style class
  lanes in the world-grid tables rooted at `[0x0062c120+0x2129]`, then clears bit `0x2` across
  the live route-link records and reruns the endpoint-pair reconciler. That now lines up with the
  visible shell split: non-route candidates keep the richer local metric and price lane, while
  route-style candidates use one world-side route-link family instead. The emission side is
  tighter now too: `placed_structure_try_emit_best_route_style_peer_link_for_candidate_class`
  `0x0040fef0` scans the live placed-structure collection for one best peer site by
  class-specific weight, distance window, and type gate, then only creates a new route-link
  through `placed_structure_route_link_allocate_site_pair_for_candidate_class` `0x00467f50` when
  `placed_structure_endpoint_pair_has_shared_route_entry_key` `0x0040fbe0` says the chosen site
  pair does not already share a route-entry key. One layer above that,
  `placed_structure_rebuild_route_style_candidate_scores_and_peer_links` `0x004101e0` now reads
  as the broader per-site owner of this lane: it computes per-class route-style score scalars from
  local site state and scenario multipliers, drives the first three route-style emission attempts,
  and then continues into a larger descriptor-driven scoring phase. Inside that larger pass,
  `placed_structure_accumulate_candidate_metric_or_emit_route_style_peer_link` `0x0042cab0`
  now cleanly shows the split between ordinary candidates, which add directly into the local
  route-style grid lane at `[site+candidate*4+0x103]`, and remapped route-style candidates, which
  re-enter the peer-link emitter. One layer above that, the broader post-create or post-edit site
  rebuild `placed_structure_finalize_creation_or_rebuild_local_runtime_state` `0x0040ef10`
  conditionally re-enters `0x004101e0` with stack flag `1` when its local latch at `[site+0x29e]`
  stays clear, so the route-style lane is no longer floating under an unnamed single-site caller.
  The placement side is tighter now too: the direct constructor
  `placed_structure_collection_allocate_and_construct_entry` `0x004134d0` is the shared allocator
  immediately beneath the current placement-side callers before they hand the new site into
  `0x0040ef10`, and the lower constructor
  `placed_structure_construct_entry_from_candidate_and_world_args` `0x0040f6d0` now bounds the
  actual field-seeding layer beneath that allocator. The old unresolved higher placement chooser is
  bounded more cleanly now too: the `0x00403ed5` and `0x0040446b` direct-placement commits sit
  inside one larger helper,
  `city_connection_try_build_route_with_optional_direct_site_placement` `0x00402cb0`. That shared
  heavy builder is now the common target of the compact wrapper `0x00404640`, the peer-route
  candidate builder `0x004046a0`, the region-entry pair wrapper
  `city_connection_try_build_route_between_region_entry_pair` `0x00404c60`, and the direct retry
  paths inside `simulation_try_select_and_publish_company_start_or_city_connection_news`
  `0x00404ce0`. Internally it now has three bounded lanes:
  an early route-entry search or synthesis attempt through
  `route_entry_collection_try_build_path_between_optional_endpoint_entries` `0x004a01a0`,
  a single-endpoint direct-placement lane that scans `Maintenance` and `ServiceTower` candidates
  and commits through `0x00403ed5 -> 0x004134d0 -> 0x0040ef10`,
  and a later paired-endpoint fallback lane that seeds two endpoint candidates from the same stem
  family, walks a temporary route-entry list, and commits through
  `0x0040446b -> 0x004134d0 -> 0x0040ef10`.
  That early lane can now be described more concretely: it can reuse supplied route-entry
  endpoints, synthesize a missing leading endpoint from the caller's coordinates, seed the
  route-store builder-state block, and then hand off to the deeper path-search core without
  placing a new site. The previously vague side family at `0x006cfcb4` is tighter too: current
  evidence now bounds it as a small auxiliary route-entry tracker collection with an allocator at
  `0x004a42b0`, a refcount or destroy path at `0x004a4340`, a direct route-entry group-id setter
  at `0x00489f80`, an endpoint-membership probe at `0x00494ed0`, a boolean-latch refresh or
  owner-notify path at `0x00494fb0`, and a two-endpoint merge or bind helper at `0x00494f00`.
  One smaller constructor-side ownership split is tighter now too: the cached `u16` chain fields
  `[site+0x26e]`, `[site+0x270]`, and `[site+0x383]` are no longer free-floating. Constructor-side
  helper `0x0041f7e0` prepends one new peer into that chain by storing the old head from
  `[this+0x383]` into `[peer+0x270]` and then replacing `[this+0x383]` with the peer's own
  placed-structure id `[peer+0x2a4]`; the direct resolver `0x0041f810` turns the cached head id
  back into one live record through `0x0062b26c`; and the removal-side companion `0x0041f850`
  removes one peer from the same chain before clearing `[peer+0x26e/+0x270]`. That caller split is
  now strong enough to treat this as one cached single-link or predecessor-chain family beneath
  placed-structure construction and rebuild rather than as unrelated scratch words.
  That bind side is tighter now too: the trackers group route entries only when a route-key-like
  value from `0x0048aa70`, the route-entry signature word `+0x22e`, and the boolean latch derived
  from byte `+0x44` all agree. The deeper handoff under that lane is no longer anonymous either:
  `route_entry_collection_search_path_between_entry_or_coord_endpoints` `0x0049d380` is now
  bounded as the internal search core that runs the first candidate sweep, quality gates, and the
  later route-extension fallbacks before returning one resolved route-entry id or `-1`. The first
  sweep now has a bounded owner at `0x0049bd40`, and the two later fallback helpers are bounded as
  the route-entry point-window coverage query `0x00494cb0` and the frontier-extension helper
  `0x0049c900`. The math side is bounded more cleanly now too: the family reuses
  `math_measure_float_xy_pair_distance` `0x0051db80` for its direct point-to-point scalar,
  `math_compute_quadrant_adjusted_heading_angle_from_xy_pair` `0x004952f0` for heading-angle
  construction, `math_normalize_subtracted_angle_delta_and_report_wrap` `0x004953c0` for wrapped
  angle-delta checks, and `math_abs_double_with_crt_special_case_handling` `0x005a152e` for the
  absolute-value side of the quality gates. Current evidence also bounds the threshold shape a
  little more tightly: the initial sweep and later extension path both reuse one signed angle-bias
  term `+/-0.181000038854627`, and the first sweep switches between a looser `1.4` and stricter
  `1.8` quality multiplier depending on route-policy byte `4` or the broader display-runtime
  preference `[0x006cec78+0x4c74]`, already grounded elsewhere as `Auto-Show Grade During Track
  Lay`.
  The small policy-byte semantics are still not fully closed, but current evidence is tighter than
  before. Literal byte `1` is now the strongest current match for direct linked-site
  endpoint-anchor creation or replacement, because the linked-site constructor and neighboring
  repair branches around `0x00480463`, `0x00480a77`, and `0x00480b69` all feed that byte into
  `0x00493cf0` before rebinding one chosen route-entry anchor through `0x0048abc0`. Literal byte
  `2` now looks broader: the later world-side caller at `0x00480cd0` and the linked-site refresh
  helper `placed_structure_refresh_linked_site_display_name_and_route_anchor` `0x00480bb0` both
  reach `0x004a01a0` with both optional endpoint-entry ids unset and that byte, so the strongest
  current read is a full linked-site route-anchor rebuild between optional endpoint entries rather
  than the narrower direct creation lane. The TrackLay side now gives one tighter user-facing
  anchor too: the live mode field `0x00622b0c` is already grounded as `Lay single track.` `0x1`
  versus `Lay double track.` `0x4`, and the small mapper `0x004955b0` collapses that state into
  the endpoint-policy bytes later passed to `0x00493cf0`, so the strongest current read is
  `policy 1 = single-track endpoint synthesis` and `policy 4 = double-track endpoint synthesis`.
  Bytes `1/2` are still the ones that enable the
  auxiliary tracker lane in `0x004a01a0`, while byte `4` now reads more narrowly as the larger
  company-side endpoint-synthesis charge inside `0x00493cf0`, because that helper feeds `-1`
  versus `-2` into the saturating company counter helper `0x00423ec0` on `[company+0x7680]`
  rather than skipping the company branch entirely. That counter is tighter now too: nearby
  company initialization seeds it to `50` when scenario byte `0x4aaf` is enabled and to sentinel
  `-1` otherwise, while the companion getter `0x004240a0` returns either the live counter or fixed
  fallback `29999`. Current language-table correlation also gives `0x4aaf` a stronger
  player-facing meaning: it is the live gate behind `Company track laying is limited...` and the
  event variable label `Company Track Pieces Buildable`. So the current strongest read is
  available track-laying capacity, not an abstract company route-budget. That site-side helper
  also closes one adjacent ownership gap: beneath
  `placed_structure_finalize_creation_or_rebuild_local_runtime_state` `0x0040ef10`, it rebuilds
  one linked site's route-entry anchor and display-name buffer. That path is tighter now than just
  “bind anchor then touch `0x006cfcb4`”: after the literal-policy-`2` rebuild succeeds it
  re-enters `aux_route_entry_tracker_collection_refresh_route_entry_group_membership` `0x004a45f0`,
  which can now be described more concretely. Its early prepass at `0x004a4380` can split one
  mismatching adjacent subchain into a fresh tracker group; its later helper at `0x004a4ce0` can
  transfer one compatible adjacent chain between neighboring groups; and the repair-side helper at
  `0x004a4ff0` can reseed a whole route-entry component into a fresh tracker when the old group id
  is missing or invalid. The regrouping pass also still rewrites compatible endpoint slots through
  `0x004950f0` and refreshes one nearby cached-match payload band through `0x00495020` before the
  helper resumes the name-buffer work. The remaining display-name side still matches the earlier
  grounded text family: copy the resolved city name when available, append civic suffixes
  `Township`, `New`, `Modern`, or `Renaissance`, append `Service Tower` or `Maintenance Facility`
  on the linked-instance class branches, and otherwise fall back through the older
  `Junction`..`Center` and `Anytown` text families.
  The higher owner-refresh side of that same tracker family is tighter now too. The reusable gate
  at `0x004a4c00` no longer looks like a stray predicate: it explicitly requires both route-entry
  trackers to keep matching cached fields `+0x18/+0x1c/+0x1d/+0x1e` and both route entries to keep
  their special side fields `+0x20e/+0x222` unset before adjacent-chain transfer is allowed. The
  collection-wide traversal sweep at `0x004a5fc0` is bounded now as the connected-component refresh
  owner over tracker field `+0x0c`, with a temporary queue at `[this+0x94]` and direct fallback
  into the reseed helper `0x004a4ff0` whenever one neighboring route entry has lost valid tracker
  ownership. Above both of those sits `aux_route_entry_tracker_collection_refresh_owner_adjacent_compatible_group_links`
  `0x004a6360`, which now reads as the owner-side latch-change refresher invoked from
  `0x00494fb0`: it starts from one owner route-entry id, confirms both bound endpoint entries agree
  on the boolean class state implied by route-entry byte `+0x44`, and then probes both endpoint
  sides for adjacent route-entry groups that can be absorbed through the `0x004a4c00 -> 0x004a4ce0`
  gate-and-transfer pair. The sibling query side is bounded now too:
  `aux_route_entry_tracker_collection_query_component_label_by_tracker_id` `0x004a6320` is the
  dirty-aware accessor for tracker field `+0x0c`, while
  `aux_route_entry_tracker_dispatch_route_entry_pair_metric_query` `0x004a65b0` is the remaining
  mode-switched lower metric dispatcher beneath the heavier chooser at `0x004a6630`, forwarding
  fixed route-entry-pair candidate sets into either `0x004a5280` or `0x004a5900` depending on the
  shared hundredths-scaled build-version query
  `runtime_query_hundredths_scaled_build_version` `0x00482e00` over `0x006cec74`. The current
  caller thresholds `>= 0x67`, `>= 0x68`, `>= 0x69`, and `>= 0x6a` now line up with executable
  build values `1.03`, `1.04`, `1.05`, and `1.06`, and the version source itself can come from
  the multiplayer companion path as well as the local executable, so this split is no longer
  best-read as a time- or era-side cutover at all. It now reads more cleanly as a pre-`1.03`
  versus `1.03+` route-metric compatibility dispatcher. That lower split is tighter now too:
  `0x004a5280` is the weighted recursive branch with heuristic ordering, per-tracker best-cost
  cache `0x006cfcac`, and prune threshold `0x006cfcb0`, while `0x004a5900` is the alternate
  recursive neighbor-walk branch that stays within compatible component labels through
  `0x004a62c0` and accumulates step and mismatch penalties over route-entry links
  `+0x206/+0x20a/+0x20e`. Above both of them,
  `aux_route_entry_tracker_query_best_route_entry_pair_metric_with_endpoint_fallbacks`
  `0x004a6630` is now bounded as the real chooser: direct fixed-pair query when both entries pass
  `0x0048b870`, otherwise endpoint-pair fallback across the two tracker groups.
  The adjacent route-style rebuild side is tighter now too: the same build-version family reaches
  `placed_structure_rebuild_route_style_candidate_scores_and_peer_links` `0x004101e0`, where build
  `1.04+` keeps one `Recycling Plant` stem-specific compatibility branch alive and build `1.05+`
  skips one older descriptor-side attenuation fallback. There is also one neighboring world-side
  compatibility lane now bounded below the same family: `placed_structure_collect_connected_component_tile_bounds_with_version_gate`
  `0x004160c0` skips one older recursive component-bounds walk through `0x00415f20` on build
  `1.03+` when scenario field `[0x006cec78+0x46c38]` is already active. The wrapper above that
  path is bounded now too: `placed_structure_map_tile_range_to_connected_component_records_with_optional_bounds_refresh`
  `0x00416170` walks the caller rectangle, maps tile keys into the component table rooted at
  `0x0062ba7c`, and only re-enters `0x004160c0` when the current owner still has no cached bounds
  and the local world or scenario suppressors stay clear. The higher neighboring raster side is
  tighter too. `world_grid_refresh_projected_rect_sample_band_and_flag_mask` `0x00418610` is the
  shared projected-rectangle helper above `world_grid_refresh_flagged_region_float_extrema_and_mean`
  `0x00415020`: it refreshes the temporary sample band at `0x0062b7d0`, publishes the surviving
  rectangle through `0x0044d410`, and on the single-sample path re-enters
  `world_grid_toggle_flagged_mask_bit0_for_nonsentinel_rect_samples` `0x004185a0` to flip mask bit
  `0x01` for the corresponding non-sentinel cells. Current grounded callers for `0x00418610` are
  the neighboring placed-structure local-runtime helper `0x00418be0` and the heavier placement
  validator `0x004197e0`, so this adjacent family now reads more like projected placement or local
  raster prep than an unowned generic world-grid scan. One neighboring caller into the same
  height-support band is tighter now too: the world-side branch at `0x00419070..0x004190f0`
  walks one admitted local window, dispatches the acceptance-gated relaxer `0x0044d6e0` once per
  cell with a one-cell radius and no immediate tail refresh, and only after that outer loop
  completes re-enters `0x0044d410` on the full surviving rectangle. The higher owner split is
  tighter now too.
  `placed_structure_build_local_runtime_record_from_candidate_stem_and_projected_scratch`
  `0x00418be0` is the broader construction or rebuild lane: resolve one candidate id from a stem,
  build projected scratch through `0x00416ec0`, then publish the projected rectangle and validate
  its side windows through `placed_structure_publish_projected_runtime_rect_globals_and_validate_side_windows`
  `0x00416620`. That publish pass is bounded now too: it stages `0x0062b308/0x0062b30c/0x0062b310`,
  validates the rectangle against route-entry coverage through
  `route_entry_collection_query_rect_window_passes_entry_type_gate` `0x00494240`, can branch into
  the special projected-slot picker `placed_structure_try_select_projected_rect_profile_slot`
  `0x00415570`, and refreshes the compact per-cell side tables through
  `world_grid_refresh_projected_rect_surface_and_region_byte_tables` `0x00414e10` before the
  finished scratch is copied into one queued runtime record and the new record re-enters
  `0x00416170` when its rectangle is valid. The smaller sibling
  `0x00419200` is now bounded beneath that same projected-rectangle family too: it is the tiny
  getter over the temporary dword cell-value bank at `0x0062b300`, flattening one caller cell
  through live world width `[0x0062c120+0x2155]` and returning the corresponding dword when the
  bank exists, else `0`. Current grounded caller is the later world-side branch at `0x0048af99`.
  The smaller sibling
  `placed_structure_clone_template_local_runtime_record_for_subject_and_refresh_component_bounds`
  `0x00418a60` now reads as the current-subject clone path above the same connected-component and
  mask-refresh helpers, returning the cloned local runtime record later stored into `[site+0x24e]`
  by `placed_structure_refresh_cloned_local_runtime_record_from_current_candidate_stem`
  `0x0040e450`. The higher wrapper above that clone path is bounded now too:
  `placed_structure_collection_refresh_local_runtime_records_and_position_scalars` `0x004133b0`
  first drains the temporary site-id queue rooted at `0x0062ba64/0x0062ba6c/0x0062ba70` through
  `placed_structure_local_runtime_site_id_queue_count` `0x00414480` and
  `placed_structure_local_runtime_site_id_queue_pop_next` `0x00413f50`, rebuilding one cloned
  local-runtime record per queued placed structure through `0x0040e450`, and only then sweeps all
  live placed structures through the side refresh helper
  `placed_structure_refresh_local_runtime_position_triplet_and_linked_anchor_followon` `0x0040ee10`.
  The constructor or ownership split beneath that family is tighter now too. The shared allocator
  `placed_structure_collection_allocate_and_construct_entry` `0x004134d0` no longer just reaches
  an anonymous `0x3e1`-byte scratch object: it first constructs one concrete placed-structure
  specialization through `placed_structure_construct_concrete_specialization_vtable_5c8c50`
  `0x0040c950`, which calls `0x0045b680` to seed the common base table `0x005cb4c0`, clear the
  derived field band `[this+0x23a..+0x26a]`, and re-enter the older base initializer
  `0x00455610`, then installs the specialization table `0x005c8c50`. The paired cleanup path at
  `0x0040c970` now reads like the matching teardown thunk: it briefly reinstalls `0x005c8c50`,
  then immediately demotes the record back to the base table through `0x0045b040 ->
  0x00455650` before the stack object is freed or unwound. The corresponding serializer entry
  `0x0040c980` is equally tight now: it simply tails into `0x0045b560`, which first re-enters the
  base serializer `0x004559d0` and then emits the derived payload bracketed by tags `0x5dc1` and
  `0x5dc2` over `[this+0x23e]`, `[this+0x242]`, `[this+0x246]`, `[this+0x24e]`, and `[this+0x252]`.
  One nearby string clue is useful but narrower than it first looked. The specialization table at
  `0x005c8c50` is immediately followed by `RadioStation` and `Radio Station`, but the local member
  method `0x0040ce60` now shows why: it compares site stem `[this+0x3ae]` against `Radio Station`,
  canonicalizes that stem to `RadioStation` on match, and then re-enters `0x0040cd70` plus
  `0x0045c150`. So those adjacent strings ground one stem-normalization lane inside the
  specialization, not the specialization name by themselves. The small virtual-slot and cached-id
  side is tighter now too. The same `0x005c8c50` table carries three literal-false stubs
  `0x0040cc10/0x0040cc20/0x0040cc30`, one literal-true stub `0x0040ccc0`, and the narrower
  linked-site-id presence predicate `0x0040ccb0`, which simply returns whether `[this+0x2a8]` is
  nonzero. Beneath the stem-normalization path, `0x0040cd70` is now bounded as the common cached
  source/candidate resolver: it clears `[this+0x3cc]` and `[this+0x3d0]`, scans source collection
  `0x0062b2fc` for a stem match against `[this+0x3ae]`, stores the matched source id into
  `[this+0x3cc]` plus the linked candidate/profile id from `[source+0x173]` into `[this+0x3d0]`,
  and when no match exists formats localized id `0x00ad` through `0x0051e980` with the current
  stem buffer. The two tiny followers `0x0040cec0` and `0x0040cee0` then resolve those cached ids
  back into concrete source and candidate records through `0x0062b2fc` and `0x0062b268`
  respectively. The derived payload and transient family under that same table is tighter now too.
  `0x0045c150` is the clear payload-loader
  counterpart to `0x0045b560`: it reinitializes the derived field band, opens the `0x5dc1/0x5dc2`
  payload bracket, restores the two payload strings into `[this+0x23e]` and `[this+0x242]`, clears
  the transient roots `[this+0x24e]`, `[this+0x256]`, `[this+0x25a]`, and `[this+0x25e]`, and then
  rebuilds follow-on specialization state through `0x0045b5f0` and `0x0045b6f0`. The neighboring
  builder pair is coherent too: `0x0045b210` formats `amb_%1_01.wav`, allocates a `0x141`-byte
  transient object, stores it at `[this+0x24a]`, and registers it through `0x0052da00`, while
  `0x0045c310` allocates the separate primary transient handle at `[this+0x246]` from payload
  strings `[this+0x23e]` and `[this+0x242]`, then publishes it through `0x00530720` and
  `0x0052d8a0`. The next rebuild layer is tighter now too. `0x0045b5f0` resolves one current
  world-position tuple through `0x0052e720 -> 0x0051f090 -> 0x00534490`, then uses that derived
  scalar to refresh the ambient-side transient again through `0x0045b210`. Above that,
  `0x0045b6f0` clears the optional handles at `[this+0x25a]` and `[this+0x25e]`, then probes and
  materializes a larger named variant family rooted in `[this+0x23e]` through strings such as
  `%1_`, `%1_Upgrade1`, `%1_Anim%2.3dp`, `%1_Upgrade1Anim%2.3dp`, and
  `%1_Upgrade1Light%2.3dp`, looping across numbered variants and publishing surviving records
  through `0x0052d8a0`. One higher timed branch is bounded now too: `0x0045baf0` advances the two
  timer-like fields `[this+0x26a]` and `[this+0x266]`, gates on nearby world-distance and
  candidate-side checks, and then formats one output around `rnd_%1_%2.wav` plus the same anim or
  light string family before dispatching through `0x00531e50` under owner `0x006d402c`. Their
  release-side companions `0x0045b160` and `0x0045c3c0` tear down those same transient roots and
  payload strings again, and the recurring service slice `0x0045be50` updates the derived scalar
  triplet `[this+0x22e]`, `[this+0x232]`, and `[this+0x236]` before republishing it through
  `0x00530720`. The string literals `amb_%1_01.wav`, `%1_Anim%2.3dp`,
  `%1_Upgrade1Anim%2.3dp`, `%1_Upgrade1Light%2.3dp`, and `rnd_%1_%2.wav` therefore ground the
  derived band `[this+0x23e..+0x26a]` as one payload-plus-transient owner family with ambient,
  animation, light, and random-sound components, rather than more linked-site or route-entry ids.
  One intermediate transient build layer is bounded now too. `0x0040cf00` first requires
  creation-mode byte `[this+0x3d4] == 1` and live seed handle `[this+0x24e]`, re-enters
  `0x0045b370(1)`, derives one scaled float from current local geometry through `[this+0x14]`,
  `[this+0x21]`, `[this+0x3a]`, and `0x005c8cf4`, and then allocates a second transient handle
  into `[this+0x25a]` through `0x00475ed0`. It follows that with one current world-position
  resolve through `0x00414450` and `0x0052e720`, several local offset-triplet writes through
  `0x00475010`, and four numbered channel updates through `0x00475030` with selector ids `1..4`.
  That is enough to bound it as another specialization-side transient-handle builder beneath the
  same payload family as `0x0045c310` and `0x0045b210`, without yet over-naming the user-facing
  subtype or effect semantics of the built handle.
  One adjacent helper block is tighter now too, and it should stay separate from the concrete
  `0x005c8c50` vtable rather than being folded into it. The small predicates
  `0x0040cc40/0x0040cc60/0x0040cc80` all follow the same `[this+0x173] -> 0x0062b268` chain into
  one linked candidate/profile record. `0x0040cc40` returns whether candidate subtype byte
  `[candidate+0x32]` equals `1`, `0x0040cc60` returns raw candidate byte `[candidate+0xba]`, and
  `0x0040cc80` returns the stricter conjunction `subtype == 1 && class == 3` using class byte
  `[candidate+0x8c]`. The current grounded caller for all three is
  `world_grid_refresh_projected_rect_sample_band_and_flag_mask` `0x00418610`, where they derive
  the two boolean mode inputs for `0x00415020`; that makes them a shared candidate-profile helper
  cluster adjacent to the specialization family, not direct overrides in the `0x005c8c50` table.
  The neighboring `0x0040ccf0` stays on the same “adjacent but not the same vtable” side of the
  boundary: it resolves one linked instance through `0x0047de00`, follows that instance's vtable
  `+0x80` owner chain, and returns candidate class byte `[candidate+0x8c]`. Current grounded
  callers at `0x00480fb5` and `0x004b03ce` compare that returned class against `3` and `4`, so the
  current safest note is simply “linked-instance candidate-class reader.” One gated collection-side
  scan in the same neighborhood is bounded now too. `0x0040cd10` first requires shell latch
  `[0x006cec74+0x1c3]` and creation-mode byte `[this+0x3d4] == 1`, then resolves the current
  subject's center world-grid cell through `0x00455f60`, reads the local site roster count and id
  list at `[cell+0xeb]` and `[cell+0xef]`, and resolves each listed placed-structure id through
  `0x006cec20`. Its current grounded caller is the broader collection sweep at `0x00413860`, so
  the strongest current read is a gated center-cell site-roster scan rather than one more direct
  specialization override.
  One small neighboring world-grid helper is grounded cleanly enough to keep too. `0x0040ccd0`
  takes one live world root, one X-like index, and one Y-like index, multiplies the Y-like term by
  world width `[world+0x2145]`, adds the X-like term, scales the resulting slot by fixed cell
  stride `0x1d7`, and returns the corresponding cell pointer under base `[world+0x2129]`. Current
  grounded callers include the placed-structure cargo-service bitset sweep around `0x0042c386` and
  several world-grid overlay passes in the `0x004525bc..0x00452bb2` range, so that helper is now
  best read as the shared `(x,y) -> world-cell*` resolver rather than another object-specific
  method.
  The next sibling table at `0x005c9750` is tighter now too, though still not fully decoded. The
  structural anchor is `map_load_city_database` `0x00474610`: that loader stages bundle tags
  `0x61a9..0x61ab`, iterates one collection, and dispatches each entry through vtable slot `+0x44`.
  In `0x005c9750`, that same slot resolves into the sibling record family beside
  `0x0041ab70/0x0041ab80`, which is enough to treat the table as the city-database entry family
  rather than a generic unresolved runtime object. The small load-side slot `0x0041ab70` simply
  jumps into `0x0045c6f0`, which restores two strings into `[this+0x32e]` and `[this+0x332]`,
  stages the same `0x61a9/0x61aa/0x61ab` tag family, and iterates the child runtime band rooted at
  `[this+0x316]`. The one real behavioral slot we recovered there is `0x0041ab80`: it refreshes
  one named handle through owner `0x006d4020`, writes the resulting handle into `[this+0x1c]`,
  queries three base floats through `0x0045c480`, and returns one scaled float derived from the
  first queried component. That method is currently called from later world-side branches at
  `0x0046e4f7`, `0x004aafee`, and `0x004ab020`. The exact user-facing semantics of the handle and
  the many constant-return virtuals in the same table are still open, but the family boundary is no
  longer arbitrary: this is now the current city-database entry vtable cluster, not another
  placed-structure specialization. One correction matters here too: the lower
  `0x00455660/0x00455800/0x00455810/0x00455930` helpers are no longer city-only. Local `.rdata`
  now shows the same shared slots under both the city-entry table `0x005c9750` and the sibling
  `Infrastructure` table `0x005cfd00`, whose constructors at `0x0048a240/0x0048a2dc/0x00490a3c`
  all re-enter `0x00455b20`, install `0x005cfd00`, and seed the same scalar-band family through
  `0x00455b70` with the literal stem `Infrastructure`. So the safest current family name for those
  low helpers is the broader `0x23a` runtime-object band rather than city-entry-only. `0x00455800`
  and `0x00455810` are simply the paired normalized coordinate getters over `[this+0x1e2]` and
  `[this+0x1ea]`, which explains why they recur all over the city-side, route-link, and
  placed-structure placement code. The narrower helper `0x00455660` sits above those getters: it
  scales the caller-supplied normalized coordinate pair, converts it through
  `0x006d4024 -> 0x0051f090 -> 0x00534490`, adds a caller-supplied integer height bias, optionally
  rounds that height through `0x005a10d0` when the auxiliary-preview gate `0x00434050` is active,
  and finally publishes the resulting world-anchor triplet through `0x00530720`. One
  serializer-side sibling is bounded too. `0x00455930` queries two triplet-like scalar bands
  through `0x0052e720` and `0x0052e880` and writes the resulting six dwords through `0x00531030`;
  its load-side stream counterpart `0x00455870` reads the same six four-byte lanes back through
  `0x00531150`, republishes the first triplet through `0x00530720`, republishes the second through
  `0x0052e8b0`, and returns the summed byte count. The tagged load-side mirror `0x004559d0`
  restores the same `[this+0x206/+0x20a/+0x20e]` band beneath tags `0x55f1..0x55f3`, then
  dispatches vtable slot `+0x4c`. The `Infrastructure` side is tighter now too. The optional child
  attach helper `0x0048a1e0` allocates and seeds one fresh `Infrastructure` child and, when the
  owner already has more than one child, clones the first child's two triplet bands into that new
  child before attaching it. The looped rebuild `0x0048dd50` then rebuilds the owner-visible
  `Infrastructure` children one ordinal at a time, tears down the higher extras above ordinal `5`,
  refreshes cached primary-child slot `[this+0x248]` when needed, and finishes with the same
  world-cell and route-side follow-on family around `0x00448a70`, `0x00493660`, and `0x0048b660`.
  The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
  `Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
  then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The
  direct route-entry side of the same family is no longer anonymous either: `0x0048e140`,
  `0x0048e160`, and `0x0048e180` are the three direct resolvers over owner fields
  `[this+0x206/+0x20a/+0x20e]` into the live route-entry collection `0x006cfca8`. Another shared
  sibling family is tight enough now too: the real
  packed-byte-triplet owner is `0x0052e680`, and the two local
  wrappers `0x00455820` and `0x00455840` both force its recursion flag on. `0x00455820` forwards
  three explicit byte arguments, while `0x00455840` unpacks one packed `u24`-style dword into
  three byte lanes first. The downstream setter writes packed byte-triplet lane `[this+0x43]`,
  defaults that lane to `0x007f7f7f` when all three bytes are zero, and when recursion is enabled
  it walks child list `[this+0x75]` through `0x00556ef0/0x00556f00` and re-applies the same packed
  update recursively to every child. The sibling `Infrastructure` table `0x005cfd00` also still
  carries three tiny fixed-return slots after the shared formatter thunk `0x00455860`: two return
  literal `0x46`, and one returns fixed float `1.25f`, so those slots are now bounded as small
  table constants rather than as missing behavior. One other sibling table is bounded enough now
  to keep separate too: local `.rdata` at `0x005c9a60` carries the same shared low `0x23a` slots
  plus table-specific overrides `0x0041f680`, `0x0041f720`, `0x0041f7b0`, `0x0041f7e0`,
  `0x0041f810`, and `0x0041f850`, with nearby literals `(%1)` and `Marker09`. The exact subtype
  name behind that table is still open, but the behavior split is strong enough: `0x0041f680`
  first refreshes the current global preview/helper owner through `0x00455de0` and then forwards
  mode `1` plus handle `[this+0x23a]` into `0x004cf830`; `0x0041f720` formats `[this+0x356]`,
  publishes the resulting shell text, and conditionally dispatches `0x00452fa0` with action
  `0x12` when world state `[0x0062c120+0x2175]` is `0` or `0x15`; `0x0041f7b0` publishes one
  fixed payload and only then jumps to `0x00453510` when that same world state is `0x12`. The
  same table also has a tighter adjacent helper strip now: `0x0041f6a0` is the direct
  `[this+0x37f] -> 0x00517cf0` slot-count query, `0x0041f6b0` is the rounded normalized-coordinate
  world-scalar query above `0x0044afa0`, and that deeper helper is no longer opaque: it first
  computes one distance-like term from the current cell to global preview-anchor fields
  `[0x0062be68+0x24/+0x1c]` through the precomputed radial helper `0x0051dc00`, samples the
  companion float raster `[world+0x1605]` at the current cell plus two 8-direction rings, keeps
  the strongest local rise above the center sample, adds one thresholded preview-scalar bias from
  `[0x0062be68+0x20]`, and then adds `0x32` more when the small global gate `0x0041fff0` passes.
  That gate itself now reads as a shared shell/preview threshold test: it returns true when
  `[0x006cec74+0x2bb] == 2`, or when the same mode dword is merely nonzero and preview scalar
  `[0x0062be68+0x20]` exceeds the float threshold at `0x005c9a9c`. `0x0041f6e0` resolves the
  current center world-grid cell and checks one packed `u16` token through `0x0042b2d0`, and
  `0x0041f6f0` is the raw byte getter over `[this+0x42]`. One nearby mode-gated flag reader is
  bounded too: `0x0041f910` returns
  literal `1` when shell mode gate `0x004338c0` is inactive or the object class dword
  `[this+0x23e]` is nonzero, and only on the class-0 path does it return the same byte
  `[this+0x42]`. The release side under that same sibling family is bounded too: `0x00420650`
  lazily seeds `[this+0x317]` from shell-profile word `[0x006cec78+0x0d]` before re-entering
  `0x00420350`, and that body is now bounded as the local scalar refresh over `[this+0x31b]`:
  it compares the seeded word against the current shell-profile word, maps the delta through one
  bounded piecewise float curve, and applies one extra affine adjustment when `[this+0x23e]` is
  nonzero. `0x00420670` then frees the optional dynamic payload at
  `[this+0x37f]`, clears the cached `u16` link chain through `0x0041f8d0`, and tails into base
  cleanup `0x00455d20`; and the small collection-side wrapper `0x00421700` simply resolves one
  entry id, re-enters `0x00420670`, and erases that id from the owning collection. The
  city-entry family also now has one tighter
  helper-object branch. `0x00474030`
  switches over mode enum `0..10`, maps those cases into `0x00475ed0` with selector families
  `4/0xd/0xe` and fixed scalar presets `0.5/0.75/1.0/1.5/2.0`, and on success publishes the
  caller-supplied world triplet through `[helper+0x4]`. The refresh helper `0x00474260` first
  reloads payload through `0x00455fc0`, then samples the current normalized coordinates plus one
  world-height scalar from `0x00448bd0`, and rebuilds `[this+0x23a]` through that same
  mode-selected helper builder using mode `[this+0x242]`. The surrounding collection-side and
  teardown helpers are tight enough now too. `0x004743d0` and `0x00474400` are the two release
  siblings over the same helper field `[this+0x23a]`: both destroy that helper through `0x00475100`
  when live and clear the field, but `0x004743d0` tails into the smaller base cleanup
  `0x00455650`, while `0x00474400` tails into the heavier dynamic-payload cleanup `0x00455d20`.
  The small predicate `0x00474430` simply returns `1` unless shell mode gate `0x004338c0` is
  active, in which case it returns byte `[this+0x42]`; the exact meaning of that flag byte is still
  open, but the mode-gated query itself is bounded now. One level higher, `0x00474450` constructs
  the collection rooted at vtable `0x005ce4a8` with fixed parameters `(0,0,0,0x14,0x0a,0,0)`, and
  bootstrap caller `0x004487a9` stores that collection into global `0x006cea50`. The collection's
  entry path is also bounded now: `0x004744a0` seeds a stack-local temporary entry through
  `0x00474110`, allocates one `0x250`-byte live record, resolves it, constructs it through
  `0x00474130`, and then tears the temporary entry down through `0x004743d0`; `0x00474510`
  resolves one entry id, releases it through `0x00474400`, and removes it from the collection. The
  collection-owned load loop at `0x00474540` sits directly beneath `map_load_city_database`
  `0x00474610`: it opens the same `0x61a9/0x61aa/0x61ab` bracket on the caller-supplied bundle,
  binds the selected path context, iterates the current collection, dispatches each record through
  vtable slot `+0x40`, accumulates the returned byte counts, and tears down the temporary entry
  after each record. That still leaves broader semantic questions open, but the current static edges
  around the city-entry family are now largely exhausted. The adjacent scaffolding is bounded too.
  Base helper `0x00455b20` initializes the shared `0x23a`-sized record family by installing base
  vtable `0x005cb1c0`, clearing the scalar bands `[+0x206/+0x20a/+0x20e/+0x22e/+0x232]`, zeroing
  the seven-dword block `[+0x212..+0x22a]`, and re-entering `0x0052ecd0`; that is why it shows up
  not only in the city-entry temporary constructor `0x00474110`, but also in several later object
  construction paths outside the city family. The city collection itself now has a bounded teardown
  side too: `0x00474480` is the small release-and-free wrapper for the collection rooted at
  `0x005ce4a8`, and teardown caller `0x004492c3` uses it before freeing the global collection
  pointer at `0x006cea50`. On the load side, `0x00445713`'s broader setup branch re-enters
  `map_load_city_database` `0x00474610` on that same global `0x006cea50` collection. Outside the
  city-specific branch, the two tiny dispatch wrappers `0x00455a40` and `0x00455a50` are also now
  bounded as raw vtable-slot helpers: the first jumps through entry slot `+0x44`, while the second
  pushes one caller argument into slot `+0x40` and then clears the global roots
  `0x006acd38/0x006acd3c/0x006acd40`. Finally, `0x00455a70` is now bounded as the generic
  current-position triplet publisher that queries `0x0052e720`, converts through
  `0x006d4024 -> 0x0051f090 -> 0x00534490`, adds a caller-supplied height bias, optionally rounds
  under `0x00434050`, and publishes through `0x00530720`. The temporary-entry constructor and live
  entry constructor are bounded now too. `0x00474110` is the tiny stack-local initializer: it
  re-enters shared base init `0x00455b20`, clears helper fields `[+0x23a]` and `[+0x242]`,
  installs vtable `0x005ce428`, and returns. `0x00474130` is the real live-entry constructor: it
  stores the entry id into `[+0x23e]`, clears the trailing helper payload block `[+0x246..+0x24e]`,
  stores mode `[+0x242]`, derives one world-height scalar from the supplied coordinate pair through
  `0x00448bd0`, builds helper field `[+0x23a]` through `0x00474030`, and then seeds the remaining
  default scalar or flag tuple through `0x00455b70` using the fixed defaults at
  `0x005ce49c/0x005ce4a0/0x005ce4a4`. That broader helper is no longer city-specific either:
  `0x00455b70` is now bounded as the shared scalar-band initializer that clears the same
  `[+0x206/+0x20a/+0x20e/+0x22e/+0x232]` family, optionally copies up to three caller-supplied
  strings into `[+0x206/+0x20a/+0x20e]`, synthesizes one default local token buffer when the middle
  string is absent, chooses one effective mode string from the third or first input, derives one
  owner handle or transform token through `0x0051f090` unless the caller suppresses that path, and
  then seeds the remaining scalar band through `0x0052edf0` and `0x0052e670`.
  The same specialization also now has one tighter UI-facing side. The override trio
  `0x0040e4e0`, `0x0040e880`, and `0x0040e9d0` all sit in the same `0x005c8c50` table and reuse
  the linked-site-capable vtable `+0x70` latch together with creation-mode byte `[this+0x3d4]`.
  `0x0040e4e0` is the strongest current owner for contextual status text: it branches across
  linked-peer checks, world-mode fields `[0x0062c120+0x2171/+0x2175/+0x2179/+0x2181]`, current
  owner state, and candidate or linked-peer display labels, then formats localized ids such as
  `0x00af`, `0x00b0`, `0x00b1`, `0x00b2`, `0x00b3`, and `0x0afd` before pushing the result through
  shell presenter `0x00538c70`. `0x0040e880` pairs with that publisher on the action side: it
  first resets the same presenter through the fixed token at `0x005c87a8`, then dispatches several
  world-side follow-ons through `0x00413620`, `0x00453510`, `0x00452db0`, and `0x00452fa0` under
  the same linked-peer and world-mode gates. `0x0040e9d0` is the narrower query-style formatter:
  when shell branch `[0x006cec74+0x74]` is live it formats one localized label with the fixed
  suffix `\nAbsIndex %d`, otherwise it can return one company-side owner label through
  `0x00426b10`, and only then falls back to `0x00455860`. So the current best read is that this
  concrete specialization owns both the ambient or animation transient family and one linked-peer
  status or action UI surface, without yet proving the user-facing subtype name.
  One smaller subtype hook cluster is tighter now too. The concrete table also carries
  `0x0040d170` and `0x0040d1b0`, both of which resolve the current candidate through cached stem id
  `[this+0x3cc]` and then test candidate dword `[candidate+0x4b]`. When that flag is nonzero,
  `0x0040d170` tail-calls the primary transient builder `0x0045c310` and `0x0040d1b0` tail-calls
  the matching release path `0x0045c3c0`. The same neighborhood now also gives direct cached-record
  resolvers instead of more anonymous pointer math: `0x0040d1f0` returns the linked peer from
  `[this+0x2a8]` through `0x006cec20`, while `0x0040d210` returns the owner-side record from
  `[this+0x276]` through `0x0062be10`. That makes the specialization-side ownership split cleaner:
  the `0x005c8c50` family is not only formatting labels and driving side effects, it also has a
  direct candidate-flag hook for building or dropping the primary transient handle.
  The last lower side reads are tighter now too. `0x0040e450` first seeds the projected-slot cache
  through `placed_structure_cache_projected_rect_profile_slot_id` `0x00414470` before it re-enters
  `0x00418a60`, and the broader stem-based builder at `0x00418be0` now has one named optional side
  renderer instead of an anonymous callsite:
  `placed_structure_render_local_runtime_overlay_payload_from_projected_bounds` `0x00418040`.
  The side refresh split is bounded now too. `0x0040ee10` publishes one local position or scalar
  triplet through the shared setter `0x00530720`, then tails into
  `placed_structure_refresh_linked_site_anchor_position_triplet_for_local_runtime` `0x0040e360`;
  that smaller follow-on only runs on the current subtype-`1`, class-`3`, linked-site branch, and
  recomputes one local-runtime triplet from the linked peer's route-entry anchor when that anchor
  is still live. The heavier sibling above that side refresh is bounded now too:
  `placed_structure_set_world_coords_and_refresh_local_runtime_side_state` `0x0040eba0` is the
  world-coordinate mutation helper that recomputes `[site+0x388]` and `[site+0x38c]`, rewrites the
  world-grid owner mapping through `0x0042c9f0` and `0x0042c9a0`, updates the subtype-`4`
  proximity-bucket family when needed, rebuilds the same local position or scalar triplet, and
  then tails into the linked-site anchor follow-on at `0x0040e360`. One later caller into that
  same side-refresh family is bounded now too: `0x00419110` clamps a caller rectangle to the live
  world bounds, resolves one per-cell bucket chain through the hashed map at `[arg0+0x88]` and
  `0x0053dae0`, and then re-enters `0x0040eba0` for every bucketed site in that rectangle using
  the stored per-entry coordinate pair plus two zero flags. Current grounded caller is the edit-side
  branch at `0x004bc851`, immediately after the neighboring nibble and companion-float mutations,
  so this now looks like a bucket-map-driven local-runtime side-state refresh wrapper rather than
  another broad site sweep.
  The sibling policy-`1` side is tighter now too. The constructor lane no longer stops at “one
  linked site id at `[site+0x2a8]`”: the subtype-`1` branch in
  `placed_structure_construct_entry_from_candidate_and_world_args` `0x0040f6d0` now clearly
  allocates that linked record through
  `placed_structure_collection_allocate_and_construct_linked_site_record` `0x00481390`, whose lower
  constructor is `placed_structure_construct_linked_site_record_from_anchor_and_coords`
  `0x00480210`. That lower constructor seeds the linked record's own id and anchor-site id, clears
  the local route-anchor and display-name fields, projects the anchor footprint into world space,
  and then either binds an already-covered route entry through `0x00417b40` or falls through into
  the neighboring policy-`1` route-entry synthesis family around `0x00493cf0` before rebinding the
  chosen route entry through `0x0048abc0`.
  The cleanup side is tighter now too. Linked-site removal now has a bounded owner at
  `placed_structure_collection_remove_linked_site_record` `0x004813d0`: it resolves the linked
  record through `0x006cec20`, runs the per-record teardown
  `placed_structure_teardown_linked_site_runtime_state_before_removal` `0x00480590`, removes the
  live entry from the collection, and only then re-enters the still-bounded company-wide follow-on
  at `0x00429c10` when the removed record passed the narrower transit-like latch. That per-record
  teardown is no longer just “clear some scratch fields.” It now clearly clears the route-style
  scratch lane, clears the five proximity buckets at `[site+0x590..0x5b8]`, detaches or invalidates
  the current route-entry anchor, frees the three per-site byte arrays at `[site+0x24..0x2c]`,
  clears this site's indexed byte from the corresponding arrays of later placed-structure records,
  and then re-enters `0x00436040` with the current site id.
  That company-side follow-on is no longer just one opaque callback either. It is now bounded as
  `company_collection_refresh_active_company_linked_transit_site_peer_caches` `0x00429c10`, which
  walks the active company roster and re-enters
  `company_rebuild_linked_transit_site_peer_cache` `0x004093d0` on each company. That per-company
  fast pass stamps a refresh tick at `[company+0x0d3e]`, clears and repopulates the
  placed-structure-side cache cells addressed through `[site+0x5bd][company_id]`, marks the
  eligible linked transit sites for that company, allocates one `0x0d`-stride peer table for each
  eligible site, and fills those peer rows from
  `aux_route_entry_tracker_query_best_route_entry_pair_metric_with_endpoint_fallbacks`
  `0x004a6630`. That helper no longer reads as one anonymous route sweep: it either uses the fixed
  pair directly or falls back across tracker endpoint combinations before returning the winning
  route-entry id, one route-step count, and one companion mismatch count. The fast cache now reads
  more cleanly too: peer-record dword `+0x05` stores that step count, while float `+0x09` stores
  the normalized continuity share derived from `(steps - mismatches) / max(steps, 1)`, not a raw
  delta-per-step ratio. The
  adjacent timed wrapper `company_service_linked_transit_site_caches` `0x00409720` now shows the
  cadence too: `0x004093d0` is the shorter-interval refresh, while the older heavier sibling at
  `0x00407bd0` was only revisited on the longer interval.
  That heavier sibling is now bounded too:
  `company_rebuild_linked_transit_autoroute_site_score_cache` `0x00407bd0` no longer looks like a
  generic tail refresh. It reuses the fast peer tables, rebuilds candidate-local amount bands plus
  normalized issue-opinion scales, and then folds the peer-side route metrics back into three
  per-site cache floats with a cleaner split:
  `+0x12` is the raw surviving site-score total,
  `+0x0e` is the continuity-and-step-weighted companion total,
  and `+0x16` is the promoted final site-ranking lane chosen from the strongest grouped candidate
  bands.
  That also closes most of the cross-version impact question:
  the pre-`1.03` versus `1.03+` tracker metric split now looks like it mainly perturbs the weighted
  `+0x0e` lane and the promoted `+0x16` lane, not the raw `+0x12` total.
  That final lane then feeds the neighboring selectors
  `company_select_best_owned_linked_transit_site_by_autoroute_score` `0x00408280` and
  `company_build_linked_transit_autoroute_entry` `0x00408380`. That makes the company-side follow-on
  read more like a linked-transit autoroute cache family than a generic company maintenance pass.
  The neighboring reachability gate is tighter now too:
  `company_query_cached_linked_transit_route_anchor_entry_id` `0x00401860` caches one company-side
  route-entry anchor, and
  `placed_structure_is_linked_transit_site_reachable_from_company_route_anchor` `0x004801a0`
  uses that anchor to decide whether a foreign linked transit site can still participate in the
  current company's fast peer cache.
  The first direct train-side consumer above that cache family is bounded now too:
  `train_try_append_linked_transit_autoroute_entry` `0x00409770`. After servicing the owning
  company's caches, it asks `0x00408380` for one staged `0x33`-byte route entry using the train's
  current anchor site, then either appends that entry through `0x004b3160` and refreshes the new
  trailing selection through `0x004b2f00`, or rotates one existing slot in place when the local
  two-entry cap has already been reached. So this edge now reaches an actual train-side autoroute
  append lane rather than stopping at anonymous company-side cache cells. The weighted cache lanes
  still do not escape that route-choice family directly: this train-side append path only inherits
  the weighted site and peer choice by calling `0x00408380`, not by reading cache `+0x0e/+0x16`
  itself.
  The train-side follow-on above that seed path is bounded now too. The owning company can count
  its live roster through `company_count_owned_trains` `0x004264c0`, measure one aggregate linked
  transit site pressure through `company_compute_owned_linked_transit_site_score_total`
  `0x00408f70`, and then rebalance that roster through
  `company_balance_linked_transit_train_roster` `0x00409950`.
  The aggregate helper no longer reads as a raw sum either:
  it starts from the site-cache `+0x12` totals, converts that into one tentative roster target
  through year and site-count ladders, and on build `1.03+` adds one special distance-side scaling
  branch when exactly two eligible linked transit sites survive.
  Because it consumes `+0x12` rather than `+0x0e` or `+0x16`, current evidence now says the tracker
  compatibility split is more important for seeded route choice and ranked site choice than for the
  final company train-count target itself. The local linked-transit chain is now bounded enough to
  say that directly: weighted cache lanes feed `0x00408280 -> 0x00408380 -> 0x00409770/0x00409830`,
  while the separate pressure or roster lane feeds `0x00408f70 -> 0x00409950` from raw `+0x12`.
  The balancer then applies two age bands to company-owned trains:
  very old trains are removed when the roster already exceeds target or upgraded when it still
  needs capacity, while the mid-age band can trigger one narrower upgrade pass.
  After that it fills any remaining deficit by either packaging multiplayer opcode `0x75` or
  locally re-entering
  `company_try_add_linked_transit_train_and_publish_news` `0x00409830`. The two visible news
  helpers under it are bounded too: `0x00409830` emits RT3.lng `2896` for a newly added train,
  while `company_publish_train_upgrade_news` `0x00409300` emits RT3.lng `2897` for the upgrade
  branch.
  The subtype-`4` sibling side is bounded now too. The nearby-site bucket family now has:
  `placed_structure_append_nearby_transit_site_distance_bucket_entry` `0x0047fdb0`,
  `placed_structure_remove_site_id_from_proximity_bucket_lists` `0x0047dd10`, and
  `placed_structure_clear_proximity_bucket_lists` `0x0047dcd0`, plus the two collection sweeps
  `placed_structure_collection_append_site_into_all_proximity_bucket_lists` `0x00481480` and
  `placed_structure_collection_remove_site_id_from_all_proximity_bucket_lists` `0x004814c0`.
  Current evidence says those five buckets store `(peer site id, distance)` pairs for nearby
  station-or-transit peers, grouped through the five-way classifier at `0x0040d350`. The older
  stream-backed side is bounded too: `placed_structure_collection_load_dynamic_side_buffers_from_stream`
  `0x00481430` walks the live placed-structure collection and re-enters
  `placed_structure_load_dynamic_side_buffers_from_stream` `0x0047d8e0`, which repopulates the
  route-entry list, the three per-site byte arrays, the five proximity buckets, and the trailing
  scratch band from the caller-supplied persistence stream.
  The linked-site route-entry list itself is tighter now too. The refresh or teardown branch at
  `0x0040e102` re-enters `placed_structure_remove_route_entry_key_and_compact` `0x0047d810`, which
  removes one matching `u16` key from the six-byte list rooted at `[site+0x462]/[site+0x466]`,
  compacts the surviving entries into a replacement buffer, and decrements the stored route-entry
  count.
  The broader company-side owner above these pieces is tighter now too. The periodic service pass
  `company_service_periodic_city_connection_finance_and_linked_transit_lanes` `0x004019e0` now
  reads as the current outer owner for this branch: it sequences the city-connection announcement
  lanes, the linked-transit train-roster balancer, the acquisition-side sibling
  `company_try_buy_unowned_industry_near_city_and_publish_news` `0x004014b0`, the annual finance-policy helper
  `company_evaluate_annual_finance_policy_and_publish_news` `0x00401c50`, and the shorter-versus-
  longer linked-transit cache refresh tail through `0x004093d0` and `0x00407bd0`. That outer pass
  also has one tighter temporary-state role now: it clears company bytes `0x0d17/0x0d18/0x0d56`,
  mirrors `0x0d17` into scenario field `0x006cec78+0x4c74` only while the earlier route-building
  side runs, and restores the original scenario value on exit. Current evidence now ties `0x0d17`
  to the shared preferred-locomotive chooser `0x004078a0`: the override is only armed when that
  helper picks one locomotive whose engine-type dword is `2`. That engine-type lane now best reads
  as electric rather than an unnamed class slot, because the linked approval helper around
  `0x0041d550` now reads as a real locomotive-era and engine-type policy gate, dispatching the same
  `0/1/2` field across three scenario-opinion lanes while the local player-facing engine-type
  family is explicitly `Steam / Diesel / Electric`. That same gate also now ties the later scenario
  bytes `0x4c97..0x4c99` back to the editor-side `Locomotives` page rather than treating them as
  anonymous availability flags: they are the live `All Steam Locos Avail.`, `All Diesel Locos
  Avail.`, and `All Electric Locos Avail.` policy bytes behind `0x004cd680` / `0x004cf0d0`. The
  current logic is also tighter than a plain override tier: a positive engine-family opinion result
  can carry the gate by itself only while none of those three editor bytes is enabled; once any of
  them is nonzero, `0x0041d550` instead requires one matching intersection between the record-local
  family bytes and the enabled editor family bytes. The `WhaleL` carveout is narrower now too:
  current data-file correlation ties that stem to the `Orca NX462` / `WhaleL_NE` locomotive family,
  and it explicitly zeros that positive-opinion result before the later family-availability checks,
  so it loses the shortcut rather than gaining a special approval path. The same
  chooser now also has a bounded fallback below it, `locomotive_collection_select_best_era_matched_non_electric_fallback_id`
  `0x00461cd0`, which explicitly skips engine-type `2` and chooses the lowest-penalty remaining
  locomotive by era mismatch and approval gates. The route-search side is tighter too: this
  electric-only override now clearly feeds the first path-sweep branch in `0x0049bd40`, forcing the
  larger `1.8` initial quality multiplier instead of `1.4`, which is the same branch otherwise
  chosen by explicit route-policy byte `4`. So the later annual finance helper is reading
  same-cycle side-channel state from the earlier city-connection and linked-transit branches, not
  unrelated long-lived finance fields. The inner
  finance helper is not debt-only either. Current grounded outcomes include bankruptcy news
  `2881`, the debt restructure family `2882..2886`, a later share-repurchase headline `2887`, and
  the dividend-side adjustment branch. The main commit verbs under that helper are now grounded too:
  `company_repay_bond_slot_and_compact_debt_table` `0x00423d70`,
  `company_issue_bond_and_record_terms` `0x004275c0`,
  `company_repurchase_public_shares_and_reduce_capital` `0x004273c0`, and
  `company_issue_public_shares_and_raise_capital` `0x00427450`. The threshold side is tighter now
  too. The earliest creditor-pressure lane requires scenario mode `0x0c`, the bankruptcy toggle
  `[0x006cec78+0x4a8f]` to be clear, at least `13` years since `[company+0x163]`, and at least
  `4` years since founding year `[company+0x157]`; it then scans the last three years of the
  derived net-profits and revenue lanes `0x2b` and `0x2c`, chooses one negative pressure ladder
  `-600000 / -1100000 / -1600000 /
  -2000000` from the current slot-`0x2c` bands around `120000 / 230000 / 340000`, requires the
  broader support-adjusted share-price or public-support scalar at least `15` or `20` depending on
  whether all three sampled years failed, checks the current fuel-cost lane in slot `0x09` against
  `0.08` times that ladder, and requires the
  three-year slot-`0x2b` total to clear one final `-60000` gate before it falls into the
  bankruptcy commit and RT3.lng `2881` headline.
  The middle debt-capital layer is split more clearly now too. With `[+0x4a8b]` clear, one annual
  bond lane first simulates full repayment through `company_repay_bond_slot_and_compact_debt_table`
  and then uses the post-repayment cash window with fixed `-250000` and `-30000` thresholds plus
  the broader linked-transit train-service latch `[company+0x0d56]` to decide whether to append one
  or more `500000` principal, `30`-year bonds. The repurchase lane is separate again: when the
  city-connection announcement-side latch `[company+0x0d18]` is set, growth setting `2` does not
  suppress it, and `[+0x4a87]` is clear, it starts from one `1000`-share batch, can replace its
  default `1.0` factor with one linked-chairman personality scalar, scales that by `1.6` when
  growth setting `1` is active, and then runs one `800000` stock-value gate plus one
  support-adjusted-share-price-times-factor-times-`1000`-times-`1.2` affordability gate before the
  repeated `1000`-share buyback commits behind RT3.lng `2887`. The ordering above this helper is
  tighter now too:
  `company_service_periodic_city_connection_finance_and_linked_transit_lanes` clears those latches
  first, runs the city-connection and linked-transit branches, and only then enters the annual
  finance helper, so these look like same-cycle reaction gates rather than long-lived balance-sheet
  flags.
  After the earlier debt or bankruptcy outcomes stay inactive, the later stock-capital lane also
  has a tighter bounded shape now too: it only opens on build `1.03+`, only after the earlier
  bankruptcy, bond, and repurchase outcomes stay inactive, and with the bond and stock toggles
  `[+0x4a8b]` and `[+0x4a87]` clear, at least two bond slots live, and at least one year since
  founding. It derives one issue batch from outstanding shares rounded down to `1000`-share lots
  with floor `2000`, trims that batch until the broader support-adjusted share-price scalar times
  batch no longer exceeds the `55000` gate, recomputes the pressured support-adjusted share-price
  scalar and the paired `price/book` ratio, then tests the remaining gates in a fixed order:
  share-price floor `22`, proceeds floor `55000`, current cash from `0x2329/0x0d` against the
  chosen highest-coupon bond principal plus `5000`, one later stock-issue cooldown gate that
  converts the current issue mixed-radix calendar tuple at `[company+0x16b/+0x16f]` through
  `calendar_point_pack_tuple_to_absolute_counter` `0x0051d3c0` and compares the result against the
  active world absolute calendar counter `[world+0x15]`, and only then the coupon-versus-price-to-book
  approval ladder `0.07/1.3 -> 0.14/0.35`. The issue mutator preserves the previous tuple in
  `[company+0x173/+0x177]` and refreshes the current tuple from `[world+0x0d/+0x11]` on the
  derived-pricing lane. On success it issues two
  same-sized tranches through repeated `company_issue_public_shares_and_raise_capital` calls and
  publishes a separate equity-offering news family rooted at localized id `4053`, not the earlier
  debt or buyback headline family.
  The dividend side is bounded too: it requires the dividend toggle `[0x006cec78+0x4a93]` to be
  clear, mode `0x0c`, at least `1` year since `[company+0x0d2d]`, and at least `2` years since
  founding, then averages the last three years of the net-profits lane `0x2b`, folds in the
  unassigned-share pool and the current `0x0d` band, applies the map-editor building-growth
  setting `[0x006cec78+0x4c7c]`, treats growth setting `1` as a `0.66` scale-down and setting `2`
  as a zeroing pass on the current dividend, quantizes surviving adjustments in tenths, and
  finally clamps against
  `company_compute_board_approved_dividend_rate_ceiling` `0x00426260`.
  The linked-transit route-seeding side has one tighter sibling now too:
  `company_reset_linked_transit_caches_and_reseed_empty_train_routes` `0x00401940`. It clears the
  two company-side linked-transit cache timestamps, forces one immediate cache rebuild through
  `0x00409720`, strips route lists from company-owned trains in modes `0x0a/0x13`, and then
  re-enters `train_try_append_linked_transit_autoroute_entry` `0x00409770` only when a train's
  route list has become empty.
  On the wider chooser question, the current evidence is also tighter than before: every recovered
  external owner of `0x00402cb0` is still in the city-connection family, so the two later direct
  placement lanes currently read as city-connection fallback behavior rather than a broadly shared
  world placement service.
  It can still unwind through route-state cleanup without committing new placed structures, so the
  exact lower helper semantics are not fully closed, but the broader chooser is no longer
  anonymous and its main policy split is now visible. The two lower helpers directly under those
  commit lanes are bounded now too:
  `placed_structure_project_candidate_grid_extent_offset_by_rotation` `0x00417840` is the shared
  projected-footprint offset helper over candidate bytes `[candidate+0xb8]` and `[candidate+0xb9]`,
  and `placed_structure_validate_projected_candidate_placement` `0x004197e0` is the shared
  go-or-no-go validator that checks company, territory, world-tile, and footprint occupancy state
  before either direct-placement commit is allowed to fire. Its strongest current subtype branch is
  a station-attachment or upgrade-style lane keyed by `[candidate+0x32] == 1`, which now has the
  concrete failure family `2901..2906`: blocked upgrade footprint, ground not flat enough, not
  your track, insufficient track-laying capacity, cannot connect to existing track, and ground too
  steep. That tightens the chooser materially without yet proving that the validator is
  station-only for every caller.
  The recurring outer owner is tighter now too:
  `placed_structure_collection_refresh_quarter_subset_route_style_state` `0x00413580` walks every
  fourth live placed structure from a scenario-time-derived offset and re-enters the per-site
  rebuild with stack flag `0`, giving the route-style lane a concrete recurring maintenance sweep
  under `simulation_service_periodic_boundary_work` rather than only a floating caller note. One
  neighboring helper is now bounded on the message side too:
  `shell_building_detail_handle_subject_value_row_band_action` `0x004ba270` switches over the
  clicked row family `0x7d07..0x7d14`, treats subject bytes `+0x21/+0x22/+0x23` as one current
  selection plus one bounded low/high pair, increments the family dirty latch at `0x006cfe0c` on
  change, and republishes the refreshed value through the shared shell control helper on code
  `0x66`. One neighboring helper is now bounded on the side-list path too:
  `shell_building_detail_propagate_selected_subject_state_into_side_list` `0x004b9ec0` walks the
  sibling list owner at `0x006cfe08`, copies the active subject state into each side-list record,
  mirrors the current service or capability id at `+0x24`, and preserves the `0x40/0x20/0x10`
  subflags from the active subject. That means the value-row actions and later selector rows now
  read as propagating one shared building-detail state across the sibling list rather than only
  mutating one isolated subject record. One neighboring helper is
  now bounded separately too: `shell_building_detail_refresh_subject_pair_value_rows` `0x004bad20`
  owns the mutually exclusive value-row pairs `0x7d07/0x7d08`, `0x7d11/0x7d12`, and
  `0x7d13/0x7d14`, choosing among them from the same selected-subject flag byte and payload fields
  at `+0x22/+0x23`, while the larger cargo-or-service row owner also gates the extra visual lanes
  `0x7d6a`, `0x7d6b`, and `0x7d9d` from that same subflag family. The asset-string block is tighter
  too: that branch family now explicitly uses `AnyCargo.imb`, `AnyFreight.imb`, `PassMail.imb`,
  `Caboose.imb`, and `Dining.imb`, with the bit-`0x20` special lane already aligned to
  `Caboose.imb` and the sibling bit-`0x10` special lane now aligned to `Dining.imb`. The larger
  `0x7f58..0x801f` band is no longer just a styled row family either:
  `shell_building_detail_present_flagged_service_capability_popup` `0x004b9fd0` is now grounded as
  its explanatory popup callback. It resolves either one fixed express-side row from `0x00621e04`
  or one active candidate or service id from `[subject+0x24]`, then formats one popup through the
  shell message-box path. The neighboring refresh helper `shell_building_detail_refresh_flagged_service_capability_rows`
  `0x004b9a20` is tighter now too: `0x7d07..0x7d1c` is not one anonymous block, but a real mask
  partition over subject bits `0x20` and `0x10`, with one zero-mask pair, one bit-`0x20`-only
  pair, one exclusive-or pair, and later one-bit and two-bit indicator rows. RT3.lng now closes
  the fixed popup text family too: the single-line branch uses
  `3922` `%1\nLoads available at %2: %3`, while the richer ordinary-candidate branch uses
  `2981` `%1\nLoads available at %2: %3     Current Price: %4` and can append
  `2982` `Price at next station, %1: %2 (%3%4)`. The selector band is narrower too: current
  refresh-side evidence shows `0x7f58..0x801f` as one selected-ordinal highlight family over the
  three fixed express rows plus the ordinary active-candidate rows, not as a generic unstructured
  list. The neighboring `0x8020..0x8051` band is tighter too: it is primarily the matching
  remove-entry family for the selected subject's live id list, with two special row indices
  re-routing into the `0x7d0f/0x7d10` subflag-clearing path instead of ordinary list compaction
  when the current `0x20/0x10` service-bit combination demands it. That means the exact captions
  are no longer broadly open across the whole selector family: the fixed express-side rows, the
  mask partitions, and the add/remove structure are grounded, and the remaining caption gap is
  mostly the ordinary candidate rows further down the same band. The top-level toggles are
  tighter now too: the paired
  `0x7d02/0x7d03` controls are the real mode switch over subject bit `0x40`, choosing between the
  bounded pair-value branch and the current-selection/status branch around `0x7d0d/0x7d0e`, while
  the smaller `0x7d0f/0x7d10` controls flip the same special-service subflags later rendered as
  `Caboose` and `Dining Car`. One adjacent control is tighter now too: the extracted
  `BuildingDetail.win` resource contains the plain-English line `Set the initial cargo amount for
  'Disable Cargo Economy' scenarios.`, and the `0x7d01` plus `0x7d09/0x7d0a` message-side branch
  can mirror the current subject or selection through
  `shell_building_detail_submit_aux_owner_subject_sync_request` `0x004b9e10` into the auxiliary
  owner queue at `[0x006cd8d8+0x8f48]`, with side-owner presence now explicitly grounded through
  `shell_has_auxiliary_preview_owner` `0x00434050`. That queued request is tighter too: both
  current callsites forward the same side-list mirror latch at `[0x006cfe08+0x0c]`, so the
  auxiliary owner now clearly sees not just the staged subject but also whether the local
  `BuildingDetail` side-list is in mirrored-subject mode. The same `0x7d01` lane also now has one
  clear rejection note: localized id `3587` `This option is only available by following the
  tutorial.` now sits behind the active tutorial flag at `0x006d3b4c` and the cached previous
  tutorial expected-control id at `0x00622b38`, while the neighboring tutorial helper
  `tutorial_advance_step_and_refresh_expected_control_ids` `0x00516be0` now grounds
  `0x00622b34/0x00622b38/0x00622b3c` as the current and previous expected-control cache rather
  than anonymous globals. The last field is tighter now too: `0x00622b3c` is currently best read
  as the active tutorial step's alternate-accepted companion control id, because the generic shell
  control path compares clicked control ids against it directly and suppresses the `3587` tutorial
  rejection when they match. That does not fully close the player-facing caption bind for every
  control, but it does bound the neighboring side-owner sync and tutorial-rejection lane instead
  of leaving it as anonymous glue.
  The extra pre-insert gate is narrower than it
  first looked. It is now grounded as tutorial-only:
  `tutorial_validate_train_route_station_indicator_step` `0x00516d00` checks the current tutorial
  step from the shell tutorial descriptor table at `0x00622b48` before a live station-or-transit
  site id can be committed into the staged route entry, and the currently accepted steps align with
  localized prompts `3777` and `3778`, the two train-routing tutorial instructions that tell the
  player to click the Milan and Turin station indicators. Outside that tutorial state family, the
  route-entry insertion path is not gated there. The adjacent validator is tighter now too:
  `train_route_list_validate_reachability_and_station_pair` `0x004b2c10` walks that same route list,
  resolves placed-structure-backed entries through the live placed-structure and route-node
  collections, uses the direct route-node payload branch for the remaining entry family, and fails
  with `3089..3091` when the resulting route cannot be traversed or does not preserve a valid
  terminal station pair. The post-validation follow-on is bounded too:
  `train_current_route_context_uses_strict_reachability_mode` `0x004a9460` is now the small shared
  gate above the stricter branch, keyed off the current linked route object's downstream class type,
  and `train_set_route_operating_mode_and_scalar` `0x004ab980` now reads as the shared train mode
  setter beneath route editing, with the local and multiplayer insertion paths choosing mode
  `0x13` only when that stricter second validation succeeds and mode `0x0a` on the looser fallback
  path. The first
  deeper world-mode interaction branch is now better
  bounded: `GameUppermost.win` hotspots, cursor drag, held Shift state, discrete shell view-step
  commands, direct keyboard turn/pan/zoom bindings, the `TrackLay.win` and `StationPlace.win`
  world-command surfaces, and a frame-owned hover or focus-target transition branch all feed the
  same shell-controller-backed path. The remaining uncertainty has moved farther from basic
  ownership: the hover-target branch clearly exists, and `0x07d6` now looks like the shared
  main-world interaction surface rather than a generic detail button for one tool family only. One
  more shell-side consumer is bounded now too: `0x004bc350` is a world-surface brush handler over
  that same `0x07d6` control plus the adjacent mode family `0x0faa..0x0faf` and ordinal strip
  `0x0fa0..0x0fa7`. That family is no longer just a generic unlabeled brush owner: the
  detail-panel manager now grounds the sibling tool-window strip immediately above it as
  `Bulldoze.win`, `ChangeHeight.win`, `ChangeTrees.win`, `PaintTerrain.win`, `PaintRegion.win`,
  `PaintSound.win`, and `PaintTerritory.win`, each with its own constructor, refresh pass, and
  message owner beneath the same controller rooted at `0x006d0818`. Once its local drag latch is
  active it dispatches the current mode dword at `[0x006d0818+0x8c]` into the companion-float
  helpers `0x0044d4e0`, `0x0044d880`, and `0x0044da70`, or into the secondary-raster nibble path
  `0x00448e20 -> 0x00419110`, so the remaining uncertainty has narrowed from ownership to the
  exact one-to-one mode-button mapping inside that grounded tool-window strip. The
  `PaintTerrain.win` side is tighter now too: constructor `0x004f7ce0` seeds shell singleton
  `0x006d1304`, callback root `0x006d1334`, a constructor-time bulk-update latch at
  `0x006d1330/0x006d1331`, and the broader terrain mode or scalar state from `0x00622748..0x00622788`
  plus `0x006d1308..0x006d1324`; it then registers the callback strip `0x004f5960`,
  `0x004f59f0`, `0x004f6070`, and `0x004f69e0` through `0x00540120`. The direct message owner
  under that same family is no longer just a loose branch fan-out either: `0x004f6f50` owns
  messages `2/0xca/0xcb`, keeps control `0x07d6` as the live world-surface drag latch, routes
  explicit undo control `0x2775` into `0x004f5c30`, maps the selector and mode strips
  `0x2711..0x2730`, `0x27d9..0x27df`, `0x283d..0x2843`, `0x28a1..0x28e6`, `0x2915..0x291e`,
  `0x2964..0x2967`, and `0x29cd..` into the cached terrain lanes, and then fans the active drag
  path into preview helpers `0x004f6930`, `0x004fb5e0`, `0x004fc280`, `0x004fc4d0`, and
  `0x004fc630` depending on the current terrain mode. Inside that same family
  `0x004f5a80/0x004f5c30` are now the bounded local undo snapshot pair, `0x004f5dd0` is the
  tiny active-scalar-group selector, `0x004f6b50` owns the ten-entry mode strip rooted at
  `0x28dd`, `0x004f6390` is the broad mode-panel repaint owner, `0x004f6250` is the
  mode-dependent world-dispatch bridge, `0x004f6930` samples the current preview raster at
  world coordinates, and `0x004fb5e0` is the heavier preview-raster rebuild and shell-surface
  publish worker. The next local helpers under that same family are tighter now too:
  `0x004f5ea0` and `0x004f5ec0` are just the two tiny special-mode predicates
  `(mode 5, variant 2)` and `(mode 4, variant 2)`, `0x004f8770` is the weighted RGB sampler
  over the current preview or undo-backed raster neighborhood, `0x004f89b0` is the local
  byte-grid connected-component grower over the eight-neighbor tables `0x00624b28/0x00624b48`,
  and `0x004f8bb0` is the main drag-path preview compositor that consumes the drag sample strip
  `[this+0xf0/+0xf4/+0xf8]`, allocates temporary float or byte grids, and then rasterizes the
  surviving preview rectangle through the current terrain descriptor tables at `0x005f3500`,
  the weighted color sampler `0x004f8770`, the component grower `0x004f89b0`, and several live
  world samplers before writing final RGBA pixels back into the preview surface. The late tail
  under that same compositor is tighter too: the mode-`4`, variant-`2` path toggles
  secondary-raster byte-2 bit `0x20` by comparing current and previous cells through
  `0x00534f40`; the broader mode-`4/5` world-facing branch samples class set `2/4/5` through
  `0x00534ec0`, re-enters `0x0044de30` and `0x0044df10`, latches pending world coordinates into
  `[0x006d1304+0x78/+0x7c]`, and rewrites the low nibble plus the signed overlay-vector planes
  through `0x00448df0`, `0x00448e20`, `0x00448ec0`, `0x00448ee0`, `0x00448e60`, and
  `0x00448e90`. After the optional mode-`5` smoothing sweep through `0x004f8370`, the publish
  tail either materializes one shell preview surface through `0x0051f090 -> 0x00534730` or, for
  the mode-`4/5` world-facing variants, converts the surviving preview rectangle back into
  world-space bounds and re-enters `0x0044e940`, `0x00452f20`, and `0x0044d410`. The companion
  preview-rebuild owner `0x004fb5e0` is tighter on entry, too: `0x004f726c` is the early
  rebuild path that first copies the live preview raster into `[this+0x118]` and snapshots undo
  state through `0x004f5a80`, while `0x004f7ada` is the later drag-active path that first
  allocates a temporary occupancy mask before rebuilding and then conditionally mirrors that
  mask through `0x00450520` on the world-mode-`0x17` side path. So the remaining uncertainty
  has narrowed again from family ownership to the exact meaning of a few per-mode scalar and
  token lanes, not to whether `PaintTerrain.win` itself is still a mixed shell/world owner. The
  same brush strip is tighter now too:
  `0x004bc210` stores the selected ordinal and refreshes one scalar caption
  from table `0x00621e24`, `0x004bc260` exposes the cached world coordinate pair plus the
  currently selected scalar, and `0x004bc290` restyles the ordinal strip `0x0fa1..0x0fa7` plus
  the mapped mode strip `0x0faa..0x0faf` against the current mode dword `[0x006d0818+0x8c]`. The
  next unresolved layer is narrower and more semantic: the setup side now has one grounded
  owner, `world_run_post_load_generation_pipeline`, and its building-side branch is no longer just
  one opaque block. We now have a region family, a region-border overlay rebuild, a region-owned
  structure-demand and placement dispatcher, and a deeper per-region worker that computes category
  demand, subtracts existing coverage, and tries candidate placements. The category map is tighter
  too: category `0` falls back to `House`, category `2` is the year-gated weighted region-profile
  family that also feeds the localized `Industry Weightings` stats panel, and category `3` now
  reaches a separate pool-driven picker whose fallback label is `Commercial` but whose aligned
  player-facing stats bucket is `City Support`. The normalized region band is tighter too:
  `world_region_normalize_cached_structure_balance_scalars` `0x00422320` no longer just writes an
  anonymous cached preview band at `[region+0x2e2/+0x2e6/+0x2ea/+0x2ee]`. Current growth-report
  evidence now grounds `[region+0x2e2]` as the weighted-profit-margin scalar and `[region+0x2ee]`
  as the annual-density-adjust scalar later formatted as a percent in `Stats - City/Region`, with
  `[region+0x2e6/+0x2ea]` left as the intermediate normalized-delta and clamped companion slots
  beneath that final adjust term. The per-region prepass feeding that normalization is tighter too:
  `0x00420d40` clears `[region+0x306/+0x30a/+0x30e]`, walks the linked placed-structure chain from
  `[region+0x383]`, accumulates two local placed-structure metrics through `0x0040ca70` and
  `0x0040ca80`, and only for class-0 candidates also folds source field `[source+0x141]` through
  `0x0040cec0` into the third accumulator before tailing into the later scalar refresh. That tail
  helper `0x00420560` is tighter now too: on class-0 regions it revisits the same linked chain and
  folds a class-mix contribution into `[region+0x312]`, with one source-derived term for candidate
  class `0`, a separate branch keyed by `[candidate+0x78c]` and `[site+0x246]` for class `2`, one
  fixed increment for class `3`, and no current contribution from class `1`. The
  remaining setup-side uncertainty has therefore narrowed
  again: the region seed and border-overlay pair clearly complete before the `Setting up Players and
  Companies...` banner is posted; `[0x006cec74+0x174]` now looks like the direct building-population
  gate; `[0x006cec74+0x178]` now looks like the direct seeding-burst gate and selected-year-adjust
  policy; and `[0x006cec74+0x68]` now aligns with editor-map mode because the same flag forces the
  `.gmp` family in the shell file coordinators while suppressing the later building and seeding
  branches and diverting the deeper region worker into alternate logic. One write side for that
  `[shell+0x178]` policy is now grounded too: inside `shell_dispatch_ui_command` `0x00464410`,
  command ids `0x9d26..0x9d28` store `command_id - 0x9d26` directly into `[0x006cec74+0x178]`,
  yielding live values `0`, `1`, and `2`. That means the later restore branch is no longer gated
  by an abstract hidden shell latch; at least one of its adjustment inputs is an explicit UI
  launch policy and current evidence still does not show that value being recovered from saved
  state. The `319` lane itself is no longer the
  open structural gap; it now clearly owns chairman-profile slot seeding, profile-record
  materialization, a shell editor surface over the same local record family, and a separate
  live-company presentation path through the company-list window. The later interior order of that
  same `319` lane is tighter now too: after the route-entry collection refresh on `0x006cfca8` it
  refreshes the auxiliary route-entry tracker collection `0x006cfcb4`, then runs
  `placed_structure_collection_refresh_local_runtime_records_and_position_scalars` `0x004133b0`,
  then a flagged world-grid cleanup sweep through the compact grid-flag query
  `0x00448af0` plus the neighboring local chunk-cell write helper `0x00533fe0`, and only after
  that the later route-entry post-pass at `0x00491c20`. The same `319` lane is tighter internally
  now too:
  before that later world and shell reactivation tail, `world_entry_transition_and_runtime_bringup`
  runs one distinct post-bundle status and runtime refresh phase that posts progress ids `0x196`
  and `0x197` through `0x005193f0/0x00540120` with paired `0x004834e0` follow-ons, refreshes the
  live event collection at `0x0062be18` through
  `scenario_event_collection_refresh_runtime_records_from_packed_state` `0x00433130`, rebuilds the
  scenario-side port-or-warehouse cargo recipe runtime tables through `0x00435630`, and then runs
  the named-candidate availability preseed through `0x00437743`. One later subphase is tighter now
  too: before the broad world-reactivation sweep it posts progress ids `0x32dc/0x3714/0x3715`,
  reloads one `0x108`-byte packed profile block through `0x00531150`, conditionally copies staged
  runtime-profile bytes back into `0x006cec7c` while latch `[profile+0x97]` is set, mirrors the
  grounded campaign-scenario bit `[profile+0xc5]` and sandbox bit `[profile+0x82]` into world
  bytes `[world+0x66de]` and `[world+0x66f2]`, and restores the selected year/profile lane through
  a tighter two-stage calendar path than before. Current local disassembly now shows the raw saved
  lane at `[profile+0x77]` first feeding helper `0x0051d3f0` with constant components
  `(month=1, day=1, subphase=0, tick=0)`, which writes the resulting Jan-1-style tuple dwords
  into `[world+0x05/+0x09]`. Only after that seed does the same lane enter one mode-sensitive
  adjustment branch: non-editor startup mode can decrement the lane by `1` or `3` depending on
  shell-state editor gate `[0x006cec74+0x68]`, shell-side selected-year-adjust policy
  `[0x006cec74+0x178]`, and the saved special-condition slot `[0x006cec78+0x4af7]`, and only that
  adjusted lane then feeds
  helper `0x0051d390` before `world_set_selected_year_and_refresh_calendar_presentation_state`
  `0x00409e80` stores the final absolute counter into `[world+0x15]` and refreshes
  `[world+0x0d/+0x11]`. That means the restore no longer reads as a direct
  `[profile+0x77] -> [world+0x15]` copy; the raw lane seeds the tuple immediately, but the final
  absolute-counter restore still depends on live shell/startup context. That dependency is tighter
  now too: current local evidence shows `[shell+0x178] == 1` decrementing the restored lane by
  `1`, `[shell+0x178] == 2` subtracting `3`, and otherwise a nonzero
  `[0x006cec78+0x4af7]` supplying the fallback `-1` branch. That field is no longer unresolved:
  current local disassembly now shows `0x00436d10` bulk-zeroing the dword table rooted at
  `[startup+0x4a7f]` through `rep stos`, which includes `+0x4af7`, while the editor-side special
  conditions owner at `0x004cb2b0/0x004cb8e0` counts and commits that same 49-entry table from the
  static rule descriptors at `0x005f3ab0`. The `.smp` save or restore family now grounds that live
  band directly too: `world_runtime_serialize_smp_bundle` `0x00446240` writes `49` dwords from
  `[world+0x4a7f..+0x4b3f]` plus one trailing scalar at `[world+0x4b43]`, and
  `world_load_saved_runtime_state_bundle` `0x00446d40` restores the same fixed `0xc8`-byte band
  symmetrically. Slot `30` in that table is localized pair `3722/3723`
  `Disable Cargo Economy`, so `+0x4af7` now reads as the live copy of that saved scenario rule,
  not a startup-runtime-only mystery latch. The neighboring fixed reads line up with the same rule
  cluster too: `+0x4aef` is slot `28` `Completely Disable Money-Related Things`, `+0x4af3` is slot
  `29` `Use Bio-Accelerator Cars`, `+0x4afb` is slot `31` `Use Wartime Cargos`, `+0x4aff` is slot
  `32` `Disable Train Crashes`, `+0x4b03` is slot `33` `Disable Train Crashes AND Breakdowns`, and
  `+0x4b07` is slot `34` `AI Ignore Territories At Startup`. So the remaining loader gap is
  narrower than before: the restore still depends on live shell policy `[shell+0x178]`, but the
  `+0x4af7` input itself is save-derived scenario rule data rather than something that requires
  runtime tracing to discover. Its read-side family is no longer isolated to the selected-year
  restore either: it also shapes the chunk size in
  `simulation_run_chunked_fast_forward_burst` `0x00437b20` and appears in candidate/local-service
  selection and station-detail-side scoring branches around `0x0047f910`, `0x00410d87`, and
  `0x005069c6`, which now makes this whole slot cluster look like broader runtime consumers of
  scenario special conditions rather than one startup-only mode enum. One file-side anchor is now
  tighter too: the checked classic and 1.05 `gmp/gms/gmx` corpus does expose the same aligned
  `0x0d64..0x0e2c` `50`-dword band as the grounded `.smp` runtime save or restore copy into
  `[world+0x4a7f..+0x4b43]`, but most checked file families only populate a sparse subset of that
  band. The first `36` dwords still behave like the older inferred fixed rule matrix with hidden
  slot `35` fixed to sentinel value `1`, while the trailing `13` unlabeled rule lanes plus one
  scalar vary much more selectively by file family. Current local corpus scans make that split
  concrete: the grounded 1.05 scenario-save family (`p.gms`, `q.gms`) stably lights lanes
  `35, 37, 39, 44, 45, 46, 47, 48`; the base 1.05 save family (`Autosave.gms`, `nom.gms`) only
  shares lane `35` stably and otherwise varies sparsely through `42`, `45`, and `47`; the checked
  grounded 1.05 maps, the lone 1.05 alt save, and the visible sandbox-family `.gmx` files keep
  only the sentinel lane `35` nonzero. So the current loader boundary is narrower than before: the
  `.smp` path still gives a grounded direct runtime-band restore, and checked `gmp/gms/gmx` files
  now show a partially populated projection of that same aligned band rather than a wholly separate
  fixed record family. The overlap against the later scalar window is now explicit too: trailing
  band indices `36..49` are byte-identical with post-window offsets `0x00..0x34`, so every nonzero
  lane in that prefix of the post-sentinel scalar window is also a nonzero lane in the aligned
  runtime-rule band. That means the real “other fields” boundary inside the post-sentinel window
  starts only at `0x0e2c`: `0x0df4..0x0e2c` is the aligned-band overlap prefix, while
  `0x0e2c..0x0f30` is the later tail that still looks like save-side scalar state. Local corpus
  scans now make that tail split more specific. The base 1.05 save family
  (`Autosave.gms`, `nom.gms`) shares a stable tail subset at relative offsets
  `0xb4`, `0xc0`, `0xe0`, `0xfc`, and `0x100`, with additional per-file lanes around them. The
  1.05 scenario-save family (`p.gms`, `q.gms`) has a much denser stable tail covering
  `0x08`, `0x0c`, `0x10`, `0x14`, `0x20`, `0x24`, `0x28`, `0x30`, `0x34`, `0x3c`, `0x5c`,
  `0x6c`, `0xa0`, `0xa8`, `0xbc`, `0xc0`, `0xc4`, `0xc8`, `0xcc`, `0xdc`, `0xe0`, `0xe4`,
  `0xe8`, `0xf4`, `0xf8`, and `0xfc`; those values still differ per save, but the occupancy is
  stable. The lone 1.05 alt save (`g.gms`) only lights `0x20`, `0x34`, `0xf0`, and `0xf4`.
  Grounded map families and classic saves keep the tail zeroed, while the only current map-side
  outlier remains `Tutorial_2.gmp` under the broad unknown map-family bucket. The immediately
  following fixed file window at `0x0df4..0x0f30` is now bounded separately as well: checked maps
  and classic saves leave that whole post-sentinel band zeroed,
  while checked 1.05 saves carry sparse nonzero dwords there, many of which decode cleanly as
  normal little-endian `f32` values. That makes the adjacent band look like a 1.05 save-only
  runtime band rather than scenario-static payload, even though its semantics are still open.
  One numeric alignment inside that band is now exact too: the tail start `0x0e2c` is the same
  relative distance from the aligned runtime-rule base `0x0d64` as live object offset `+0x4b47`
  is from grounded world-rule base `[world+0x4a7f]`, so the bounded tail window
  `0x0e2c..0x0f30` is offset-aligned with live bytes `[world+0x4b47..+0x4c4b]`. The first
  grounded live field at that boundary is no longer anonymous. `0x004367c0` sets one outcome mode
  in `[world+0x4a73]`, zeros `[world+0x4d]`, snapshots the selected-year lane to `[world+0x4c88]`,
  and then copies localized id `2923` `You lose.` or `2924` `You win, cheater...` into
  `[world+0x4b47]`; `0x00472dd0` formats localized id `3918` `%1 has won the game!` with one live
  profile name and writes that string into the same destination; and one compact runtime-effect
  branch inside `world_apply_compact_runtime_effect_record_to_resolved_targets` `0x00431b20` resets
  the same destination to the fixed placeholder token at `0x005c87a8`. That gives a grounded live
  interpretation for the start of the tail: `[world+0x4b47]` is the start of a victory or outcome
  status-text buffer, not a float lane. The same evidence also gives a useful caution: those live
  helpers copy up to `0x12c` bytes into `[world+0x4b47..+0x4c73]`, so the current bounded file-tail
  window `0x0e2c..0x0f30` cuts through the first `0x104` bytes of a grounded text field rather
  than ending on a clean live-field boundary. One small continuation probe now tightens that edge:
  the remaining file window `0x0f30..0x0f58` is exactly the last `0x28` bytes needed to reach the
  clean live-field boundary at `[world+0x4c73]`, and checked 1.05 saves still carry sparse nonzero
  bytes in that continuation window rather than a trailing text-looking suffix. Checked 1.05 save
  bytes in the aligned region therefore still do not resemble preserved text; they stay mostly zero
  at the beginning and many nonzero lanes decode as ordinary `f32` values. So the safest current
  note is: the tail is offset-aligned with the live object beyond `+0x4b43`, but it is not yet a
  validated byte-for-byte mirror of the live `[world+0x4b47]` status-text buffer, and the current
  nonzero save-side content continues right up to the first clean field edge at `0x0f58`. The next
  exact grounded fields after that edge are byte lanes, not restored dwords: `0x0f59` maps to
  `[world+0x4c74]` `Auto-Show Grade During Track Lay`, `0x0f5d` maps to `[world+0x4c78]`
  `Starting Building Density Level`, `0x0f61` maps to `[world+0x4c7c]` `Building Density Growth`,
  `0x0f65` maps to grounded dword `[world+0x4c80]` `leftover simulation time accumulator`, and
  `0x0f6d` maps to byte `[world+0x4c88]` `selected-year lane snapshot`. The first later grounded
  dword after that is `[world+0x4c8c]` at `0x0f71`. That means the simple 4-byte file-lane model
  stops matching grounded live field boundaries immediately after the text-buffer edge: the post-
  `0x0f58` file bytes are still offset-correlated to live state, but they are no longer naturally
  dword-aligned with the next grounded object fields. The new byte-neighborhood probe makes the
  mismatch more concrete. In checked 1.05 scenario saves, the exact grounded byte offsets
  themselves do not look like clean selector values: `p.gms` carries `0x33` at `0x0f5d` and `0x8c`
  at `0x0f6d`, while `q.gms` carries `0xcc` and `0xba` at those same offsets. The only clean
  float-looking starts in that neighborhood instead appear one byte earlier, at `0x0f5c` and
  `0x0f6c`: `p.gms` decodes those as roughly `7.6` and `6.0172`, while `q.gms` decodes them as
  roughly `23.6` and `44.6824`. That tightens the current read further: the checked save bytes
  remain offset-correlated to the live `[world+0x4c74..+0x4c8c]` neighborhood, but they are still
  not a validated byte-for-byte mirror of the exact live field layout. Local
  A second byte-oriented neighborhood immediately after that now has the same kind of split rather
  than a clean restored-field mirror. The earlier grounded anchors in that band all stay zero in
  the checked 1.05 saves: exact file offset `0x0f87` maps to selected-year bucket companion scalar
  `[world+0x4ca2]`, while `0x0f93` and `0x0f97` map to the two startup-dispatch reset-owned bands
  `[world+0x4cae]` and `[world+0x4cb2]`, and the local corpus leaves all three exact dword starts
  zeroed. The same is true for the later exact byte-owned policy lanes: file offsets `0x0f78`,
  `0x0f7c`, `0x0f7d`, and `0x0f7e` map cleanly to grounded byte fields `[world+0x4c93]` and
  `[world+0x4c97..+0x4c99]`: the linked-site removal follow-on gate plus the three editor
  locomotives-page policy bytes `All Steam Locos Avail.`, `All Diesel Locos Avail.`, and `All
  Electric Locos Avail.`. In the checked 1.05 save corpus those four exact byte lanes all stay
  `0`, which is at least structurally clean. The later grounded dword fields in the same
  neighborhood are less direct again. Exact file offset `0x0f9f` maps to `[world+0x4cba]` (the
  station-list selected-station mirror) and exact offset `0x0fa3` maps to cached
  available-locomotive rating `[world+0x4cbe]`, but the checked save bytes at those exact dword
  starts do not look like clean preserved ids or floats. The only stable float-looking starts sit
  three bytes earlier, at `0x0f9c` and `0x0fa0`: `p.gms` yields roughly `96.8754` and `186.4795`,
  `q.gms` yields `329.9467` and the same `0x0fa0`-side candidate shape, `g.gms` yields `7.0` and
  `95.8507`, and `Autosave.gms` only shows the later `0x0fa0` candidate at about `68.2629`. So
  this later band now has the same conservative read as the post-text one: the save bytes are
  still offset-correlated to grounded live fields, but the exact live byte or dword layout is not
  yet validated as a direct on-disk mirror.
  One more structural cut is now grounded beyond that neighborhood. The aligned scalar plateau
  `0x0fa7..0x0fe7` ends exactly at the later recipe-book root `[world+0x0fe7]` already grounded in
  the port-or-warehouse cargo editor and runtime rebuild path. We still do not have live semantic
  names for the plateau itself, but its aligned dword run now splits cleanly by save family. The
  base 1.05 saves (`Autosave.gms`, `nom.gms`) carry one stable signature with
  `0x0faf = 0x8000003f`, `0x0fb3 = 0x75c28f3f`, repeated `0x75c28f3c` lanes through `0x0fbf`, a
  sign-flipped lane `0x0fc3 = 0xa3d70a3c`, one tiny marker at `0x0fc7 = 0x0000003b`, and
  `0x0fcb = 0x00300000`. The scenario-save family (`p.gms`, `q.gms`) carries a different stable
  plateau over the same offsets, beginning `0x0faf = 0x4000003f`, `0x0fb3 = 0xe560423f`, then
  `0x03126f3b`, `0x1374bc3c`, and paired `0x23d70a3c` lanes at `0x0fbf/0x0fc3`, with
  `0x0fc7 = 0x0000003c`. The alt-save family (`g.gms`) follows the base signature through
  `0x0fc7`, then diverges sharply into the same `0xcdcdcd..` fill pattern already seen in its
  earlier header lanes. So the current best fit for `0x0fa7..0x0fe7` is a family-shaped aligned
  scalar plateau that belongs to save-side runtime state and terminates immediately before the
  grounded recipe-book block, not one more directly named live-field mirror. One conservative
  loader-side summary probe now starts exactly at that recipe root instead of extending the plateau
  model further. The fixed recipe-book block spans twelve books from `0x0fe7` with stride `0x4e1`,
  and the checked map/save pairs `Alternate USA.gmp -> Autosave.gms`, `Southern Pacific.gmp ->
  p.gms`, and `Spanish Mainline.gmp -> g.gms` preserve that rooted block byte-for-byte in the
  sampled local corpus. The current probe therefore treats it as preserved scenario payload rather
  than save-only runtime drift and only reports per-book signatures: a coarse head kind over the
  pre-line region, the raw `book+0x3ed` annual-production dword, and one raw summary for each of
  the five fixed `0x30`-byte cargo lines beginning at `book+0x3f1`: coarse line kind, raw mode
  dword, raw annual-amount dword, and the raw supplied/demanded cargo-token dwords at `+0x08` and
  `+0x1c`. That is enough to separate zero, `0xcd`-filled, and mixed books or lines without
  overstating line semantics beyond the grounded editor/runtime ownership already documented below.
  Local
  corpus clustering now makes the remaining split more specific. The base 1.05 save family
  (`Autosave.gms`, `nom.gms`) shares a narrow tail-heavy subset with stable relative offsets
  `0xec`, `0xf8`, `0x118`, `0x134`, and `0x138`, while still varying in value across files. The
  1.05 scenario-save family (`p.gms`, `q.gms`) shares a much broader stable set spanning almost the
  whole window from `0x04` through `0x134`, again with per-file scalar differences but consistent
  occupancy. Pairwise compare runs tighten that read further: `Autosave.gms` vs `nom.gms` does not
  preserve one common numeric tail signature even at the shared base-save offsets, and `p.gms` vs
  `q.gms` keeps the broad scenario-save occupancy pattern but still changes every shared value, with
  `q.gms` additionally lighting two extra lanes at `0x78` and `0x84`. So the current best fit is
  “family-shaped live scalar state” rather than family-default constants. The lone 1.05 alt-save
  sample (`g.gms`) only lights up four lanes at `0x58`, `0x6c`,
  `0x128`, and `0x12c`. The checked 1.05 maps and classic saves stay zero in that same bounded
  window, which strengthens the current read that this is runtime-save scalar state rather than
  generic map payload. One older unknown map-family outlier in the local corpus does still carry a
  populated window: `Tutorial_2.gmp` under the classic install tree. So the safest current note is
  “zero for grounded map families and classic save families, nonzero for observed 1.05 save
  families, with one older unknown-map exception.” Static consumer grounding is still sparse for
  that tail: direct object-offset hits currently only name the trailing scalar `[world+0x4b43]`
  through the editor panel and `.smp` save or restore family, while local opcode searches do not
  yet surface equally direct reads for the intervening `+0x4b0b..+0x4b3f` tail lanes. So the
  save-file family clustering is now strong, but those later tail scalars remain structurally
  bounded rather than semantically named. The
  same branch is no longer world-entry-only either: current local
  disassembly now shows the identical lane-adjust and
  `0x51d3f0 -> 0x51d390 -> 0x409e80` sequence in the post-fast-forward selected-year tail at
  `0x004370e0`, which lines up with the existing post-fast-forward callers already mapped under
  `0x00433bd0`, `0x00435603`, `0x0041e970`, and `0x00436af0`. That restore now
  also has some neighboring slot semantics bounded well enough to carry in the loader notes. Slot
  `31` `[0x006cec78+0x4afb]` is no longer best read as an unnamed runtime cargo-economy latch:
  local disassembly now ties it directly to the saved special-condition table entry `Use Wartime
  Cargos`, and the strongest current runtime owner is
  `structure_candidate_collection_refresh_cargo_economy_filter_flags` `0x0041eac0`. Inside that
  candidate-collection sweep the branch at `0x0041ed37` only activates when slot `31` is set and
  then treats the string family `Clothing`, `Cheese`, `Meat`, `Ammunition`, `Weapons`, and
  `Diesel` as one special cargo set before writing the live candidate filter byte `[entry+0x56]`.
  That makes the old read-side note around `0x00412560` tighter too: the neighboring descriptor
  gate is now best understood as using the live copy of the `Use Wartime Cargos` scenario rule,
  not an anonymous cargo-economy mode byte. Slot `34` `[0x006cec78+0x4b07]` is similarly bounded
  on the runtime side: the wrapper at `0x004013f0`, which sits immediately above the broader
  company-start or city-connection chooser `0x00404ce0`, snapshots region dword `[entry+0x2d]`
  across all `0x18` live region records in `0x006cfc9c`, zeros that field while the chooser runs,
  and then restores the original values on exit. That is a strong current fit for the editor rule
  `AI Ignore Territories At Startup`, even though the exact meaning of region field `+0x2d`
  remains open. Slot `29` `[0x006cec78+0x4af3]` is less semantically tidy but still worth carrying
  as a bounded consumer family: the branch at `0x0041d286` activates one later placed-structure or
  building-side scoring path only when that slot is nonzero and the linked candidate or era record
  at `[entry+0x41]` equals `5`, while two already-grounded world helpers
  `world_scan_secondary_grid_marked_cell_bounds` `0x0044ce60` and
  `world_service_secondary_grid_marked_cell_overlay_cache` `0x0044c670` also gate on the same
  slot. So the identity of slot `29` as saved rule data is grounded, but the downstream runtime
  semantics are still mixed enough that the loader should preserve the raw value without trying to
  rename its whole consumer family yet. The neighboring train-safety slots are now bounded enough
  to keep as a cautious runtime split too. Slot `33` `[0x006cec78+0x4b03]`
  `Disable Train Crashes AND Breakdowns` is the coarse gate in the currently recovered train-side
  deterioration family around `0x004af8a0`: the very first branch at `0x004af8ab` jumps straight
  to the function tail when the slot is set, bypassing the year-scaled threshold build, the later
  random or threshold comparison, and the two follow-on state transitions at `0x004ad7a0` and
  `0x004ada00`. Slot `32` `[0x006cec78+0x4aff]` `Disable Train Crashes` is narrower in the same
  family: after the threshold path has already run, the branch at `0x004af9c1` uses slot `32` to
  suppress only the lower failure-transition path and force the milder follow-on at `0x004ada00`.
  That same slot-`33` read also appears in the smaller train-side scalar query at `0x004ac460`,
  where setting it returns one fixed float immediately before the ordinary route-object-dependent
  calculation runs. So the current best loader-facing read is: slot `33` is the broad train
  deterioration bypass, slot `32` is the narrower crash-only branch inside that same family, but
  the exact player-facing names of the two unnamed train helpers still need one more naming pass.
  That restore now
  also has one concrete file-side correlation in the classic `.gms` family: local save inspection
  now consistently finds `0x32dc` at `0x76e8`, `0x3714` at `0x76ec`, and `0x3715` at `0x77f8` in
  `Autosave.gms`, `kk.gms`, and `hh.gms`, leaving one exact `0x108`-byte span from `0x76f0` to
  `0x77f8` between `0x3714` and `0x3715`. That span already carries staged-profile-looking payload
  text such as `British Isles.gmp`, so the current static-file evidence now supports the atlas-side
  `0x108` packed-profile note for the classic save family even though the exact field layout inside
  that block is still unresolved. The same classic corpus is tighter now too: inside that
  `0x108` span the map-path C string begins at relative offset `0x13`, the display-name C string
  begins at `0x46`, the block is otherwise almost entirely zeroed, and the three local samples are
  byte-identical except for the leading dword at `+0x00` (`3` in `Autosave.gms` and `hh.gms`,
  `5` in `kk.gms`). The currently atlas-tracked bytes `[profile+0x77]`, `[profile+0x82]`,
  `[profile+0x97]`, and `[profile+0xc5]` are all `0` in that classic sample set, so the current
  file-side evidence grounds the block boundaries and the embedded strings but does not yet show
  live examples of those branch-driving latches being set. One 1.05-era file-side analogue is now
  visible too, but only as an inference from repeated save structure rather than a disassembly-side
  field map: local `.gms` files in `rt3_105/Saved Games` carry one compact string-bearing block at
  `0x73c0` with the same broad shape as the classic profile slab, including a leading dword at
  `+0x00`, one map-path string at `+0x10`, one display-name string at `+0x43`, and a small
  nonzero tail around `+0x76..+0x88`. In that 1.05 corpus the analogue bytes at relative `+0x77`
  and `+0x82` are now nonzero in every checked sample (`Autosave.gms`/`nom.gms` show `0x07` and
  `0x4d`; `p.gms`/`q.gms` show `0x07` and `0x90`; `g.gms` shows `0x07` and `0xa3`), while
  relative `+0x97` and `+0xc5` remain `0`. The compared 1.05 save set is tighter now too:
  `Autosave.gms` and `nom.gms` cluster together on `Alternate USA.gmp` with `+0x82 = 0x4d`,
  `g.gms` carries `Spanish Mainline.gmp` with `+0x82 = 0xa3`, and `p.gms`/`q.gms` cluster on
  `Southern Pacific.gmp` with `+0x82 = 0x90`; across all five files the same inferred analogue
  lane at `+0x77` stays fixed at `0x07`, while the same map- or scenario-sensitive tail word at
  `+0x80` tracks those `0x4d/0xa3/0x90` byte lanes (`0x364d0000`, `0x29a30000`, `0x1b900000`).
  The leading dword at `+0x00` also splits the same corpus, with `Autosave.gms` alone at `3` and
  the other four checked 1.05 saves at `5`. That is enough to say the wider save corpus does
  contain nonzero candidates for two of the atlas-tracked profile lanes, and that one of them
  varies coherently with the loaded scenario family, but not yet enough to claim that the 1.05
  block reuses the exact same semantic field assignments as the classic one. The loader-side
  family split is tighter now too: `p.gms` and `q.gms` no longer live under a generic fallback;
  their save headers now classify as one explicit `rt3-105-scenario-save` branch with preamble
  words `0x00040001/0x00018000/0x00000746` and the early secondary window
  `0x00130000/0x86a00100/0x21000001/0xa0000100`, while `g.gms` now classifies as a second
  explicit `rt3-105-alt-save` branch with the different preamble lane
  `0x0001c001/.../0x00000754` and early window
  `0x00010000/0x49f00100/0x00000002/0xa0000000`. That branch now carries the same bootstrap,
  anchor-cycle, named 1.05 trailer, and narrow profile-block extraction path as the other 1.05
  saves. The bridge just below that trailer is now explicit too: the common 1.05 save branch
  carries selector/descriptor `0x7110 -> 0x7801` in `Autosave.gms` and `0x7110 -> 0x7401` in
  `nom.gms`, and both still reach the same first later candidate at
  `span_target + 0x189c`, well before the packed profile at `span_target + 0x3d48`; the
  `rt3-105-alt-save` branch instead carries `0x54cd -> 0x5901` and its first later candidate
  lands at `packed_profile + 0x104`, essentially on the profile tail; the scenario-save branch
  still diverges locally with `0x0001 -> 0x0186` and never enters that later `0x32c8`-spanned
  bridge at all. The common-branch bridge payload is narrower now too: both checked base saves
  expose the same 0x20-byte primary block at `0x4f14` followed by the same denser secondary block
  at `0x671c`, `0x1808` bytes later, and that secondary block now appears to run intact up to the
  packed-profile start at `0x73c0` for a total observed span of `0xca4` bytes. The trailing slice
  of that secondary block is now typed one level further: a small header at `secondary+0x354`
  carries the observed stride `0x22`, capacity `0x44`, and count `0x43`, followed by a fixed-width
  67-entry name table starting at `secondary+0x3b5` and running through names like
  `AluminumMill`, `AutoPlant`, `Bakery`, `Port00..11`, and `Warehouse00..11`, with a short footer
  (`dc3200001437000000`) after the last entry. The trailing per-entry word is now surfaced too:
  most entries carry `0x00000001`, while the currently observed zero-trailer subset is
  `Nuclear Power Plant`, `Recycling Plant`, and `Uranium Mine`. That footer is tighter now too:
  it parses directly as `0x32dc`, `0x3714`, and one trailing zero byte, so the shared
  map/save catalog currently ends on the same two grounded late-rehydrate progress ids that the
  classic staged-profile band already exposed. The strongest structural read is therefore that the
  entire `0x6a70..0x73c0` catalog region is shared verbatim between `Alternate USA.gmp` and the
  derived `Autosave.gms`, not rebuilt independently during save. Combined with the earlier
  grounded record-layout work under `0x00437743`, `0x00434ea0`, and `0x00434f20`, the current
  safest semantic read is that this shared catalog is the bundled source form of the scenario-side
  named candidate-availability table later mirrored into `[state+0x66b2]`, with each entry's
  trailing dword now reading as the same availability override bit later copied into
  `[candidate+0x7ac]`. The loader-side coverage is tighter now too: the same table parser now
  attaches both to the common-save bridge payload and directly to the fixed source range in
  `.gmp` files and the non-common `rt3-105-scenario-save` / `rt3-105-alt-save` branches. That
  makes the scenario variation explicit instead of anecdotal. `Alternate USA` keeps only three
  zero-availability names in this table (`Nuclear Power Plant`, `Recycling Plant`, `Uranium
  Mine`), `Southern Pacific` widens the zero set to twelve (`AutoPlant`, `Chemical Plant`,
  `Electric Plant`, `Farm Rubber`, `FarmRice`, `FarmSugar`, `Nuclear Power Plant`, `Plastics
  Factory`, `Recycling Plant`, `Tire Factory`, `Toy Factory`, `Uranium Mine`), and `Spanish
  Mainline` widens it again to forty-two, including `Bauxite Mine`, `Logging Camp`, `Oil Well`,
  `Port00`, and the `Warehouse00..11` run while also flipping `Recycling Plant` back to
  available. The header lanes just ahead of the table vary coherently with those scenario
  branches too: `Alternate USA` carries `header_word_0 = 0x10000000`, `Southern Pacific`
  carries `0x00000000`, and `Spanish Mainline` carries `0xcdcdcdcd`, while the structural
  fields from `header_word_2` onward remain stable (`0x332e`, `0x1`, `0x22`, `0x44`, `0x43`)
  and the 9-byte footer still decodes as `0x32dc`, `0x3714`, `0x00` in all three checked maps.
  A wider corpus scan over the visible `.gmp`/`.gms` files makes those two anonymous header
  lanes less mysterious too: the parser currently sees only three stable
  `(header_word_0, header_word_1)` pairs across 79 files with this table shape, namely
  `(0x00000000, 0x00000000)`, `(0x10000000, 0x00009000)`, and
  `(0xcdcdcdcd, 0xcdcdcdcd)`. The zero-availability count varies widely underneath the first and
  third pairs (`0..56` under the zero pair, `14..67` under the `0xcdcdcdcd` pair), so those two
  lanes no longer look like counts or direct availability payload; the safest current read is
  that they are coarse scenario-family or source-template markers above the stable
  `0x332e/0x22/0x44/0x43` table header, with `0xcdcdcdcd` still plausibly acting as one reused
  filler or sentinel lane rather than a meaningful numeric threshold. Current exported
  disassembly notes still do not ground one direct loader-side or editor-side consumer of
  `header_word_0` or `header_word_1` themselves, so that family-marker read remains an
  inference from corpus structure rather than a named field assignment.
  The new loader-side compare command makes the save-copy claim sharper too: for the checked
  pairs `Alternate USA.gmp -> Autosave.gms`, `Southern Pacific.gmp -> p.gms`, and
  `Spanish Mainline.gmp -> g.gms`, the parsed candidate-availability table contents now match
  exactly entry-for-entry, with the only reported differences being the outer container family
  (`map` vs `save`) and source-kind path (`map-fixed-catalog-range` vs the save-side branch).
  has the explicit companion `world_refresh_selected_year_bucket_scalar_band` `0x00433bd0`, which
  rebuilds the dependent selected-year bucket floats after the packed year changes; and then
  rehydrates the named locomotive availability collection at `[world+0x66b6]` through
  `locomotive_collection_refresh_runtime_availability_overrides_and_usage_state` `0x00461e00`.
  That locomotive-side restore is tighter now too: its tail explicitly re-enters
  `scenario_state_refresh_cached_available_locomotive_rating` `0x00436af0`, which rebuilds one
  cached available-locomotive rating at `[state+0x4cbe]` from the current year plus the strongest
  surviving available locomotive-side rating scalar `[loco+0x20]`, and the tiny query sibling
  `0x00434080` is now bounded as the shell-side clamped read helper over that same cached field,
  with the grounded shell-side reader later bucketing that value against `40/50/70/85/100`. The
  same rehydrate band also refreshes the live structure-candidate filter and year-visible counts
  through `structure_candidate_collection_refresh_filter_and_year_visible_counts` `0x0041e970`,
  rebuilding the paired per-slot bands at `[candidates+0x246]` and `[candidates+0x16e]` and the
  aggregate counts at `[candidates+0x31a]` and `[candidates+0x242]`; the same late checkpoint also
  re-enters `placed_structure_collection_seed_candidate_subtype2_runtime_latch` `0x00434d40`,
  which seeds runtime dword `[candidate+0x7b0]` across subtype-`2` candidate records before the
  later world-wide reactivation sweep. That checkpoint also now has an explicit shell-facing scalar
  publisher: `world_publish_shell_controller_progress_scalar_from_year_thresholds_or_selector_overrides`
  `0x004354a0` writes one clamped `0..255` value into the current shell presentation object,
  sourcing it either from the shell selector override pairs or from the scenario-side year-threshold
  band rooted at `[state+0x3a/+0x51/+0x55/+0x59/+0x5d/+0x61]`; and just ahead of the later
  scenario-side recipe rebuild, the same band also re-enters
  `scenario_state_ensure_derived_year_threshold_band` `0x00435603`, which only falls into its
  heavier rebuild body while `[state+0x3a] < 2` and otherwise leaves the derived year-threshold
  companion slots `[state+0x51/+0x55/+0x59/+0x5d/+0x61]` unchanged. The neighboring late status
  checkpoints around progress ids `0x196` and `0x197` also share one explicit stage gate now:
  `world_query_global_stage_counter_reached_late_reactivation_threshold` `0x00444dc5` compares the
  global counter `0x00620e94` against threshold `0x9901`, and the two current callers use a
  negative result to clear `[world+0x39]` before the broader world and shell reactivation sweep.
  The later reactivation tail is tighter now too: it includes the region-center world-grid flag
  reseed pass
  `0x0044c4b0`, which clears bit `0x10` across the live grid and then marks one representative
  center cell for each class-`0` region through `0x00455f60`; its immediate sibling `0x0044c450`
  then reruns `placed_structure_rebuild_candidate_cargo_service_bitsets` `0x0042c690` across every
  live grid cell. The small secondary-raster premark helper `0x0044c570` is bounded now too: it
  only admits cells whose current raster byte has no bits in mask `0x3e` and whose parallel class
  query `0x00534e10` is false, then rewrites that masked class field to `0x02` and widens the same
  cached bounds-and-count band `[world+0x21c6..+0x21d6]`. The next helper `0x0044ce60` scans the secondary raster at `[world+0x2135]`
  for cells with any bits in mask `0x3e`, caching min/max bounds plus a marked-cell count in
  `[world+0x21c6..+0x21d6]`; the larger sibling `0x0044c670` then consumes those cached bounds to
  normalize the same raster and rebuild one dependent overlay/cache surface before the later
  route-style rebuild, shell-window, and briefing branches. That overlay side is tighter now too:
  after `0x0044c670` resolves scaled surface dimensions through `0x00534c50`, it walks one local
  `3 x 32` sample lattice through the static offset tables at `0x00624b28/0x00624b48`, keeps only
  secondary-raster classes `4..0x0d`, folds several interpolated `0x0051db80` samples into one
  strongest local score, writes packed overlay pixels into the staged surface buffer, and only then
  publishes that staged overlay through `0x00534af0`. The lower helper layer under that overlay
  pass is tighter now too: `0x00534e10` is the reusable secondary-raster class-set
  predicate for classes `1/3/4/5`, `0x00534e50` is the smaller neighboring class-subset predicate
  for `1/4`, `0x00534ec0` covers `2/4/5`, `0x00534f00` covers `3/5`, `0x00534e90` is the
  marked-bit query over the same 3-byte cell family, and the nearby local counter `0x0044bdb0`
  is now bounded as the 8-neighbor count companion for that same `2/4/5` subset, walking the
  shared `0x00624b28/0x00624b48` offset tables and re-entering `0x00534ec0` on each bounded
  neighbor cell. The first caller cluster around `0x0044bf9d..0x0044c37b` therefore reads as a
  secondary-raster neighborhood service band rather than a generic map scan.
  `0x00533e70` and `0x00534160` are the coarser siblings over the overlay table at `[world+0x1685]`:
  the first clears coarse chunk objects across one clamped rectangle, while the second ensures one
  chunk object and seeds local marks through its deeper stamp helper. One level up, the neighboring
  rect owner `0x005374d0` now reads as the shared secondary-overlay refresh pass: it reruns the
  local sample and unsigned-word reducers `0x00536230/0x00536420`, rebuilds the signed vector byte
  planes through `0x00536710`, and then rebuilds the multiscale support surfaces through
  `0x00533890`, whose inner reducers now explicitly target the packed sample-triplet buffer plus
  the float and unsigned-word support planes rooted at the five-entry per-scale families
  `[world+0x15f1..+0x1601]`, `[world+0x1605..+0x1615]`, and `[world+0x1619..+0x1629]`. The setup
  side of that same family is tighter now too:
  `0x005375c0` is the shared ensure-and-seed owner that allocates the sample, sidecar, mask,
  raster, vector, and coarse-cell tables together; crucially, it seeds `[world+0x1655]` with byte
  `0x02` and `[world+0x1659]` with byte `0x01`, which closes the default-fill split. The local
  component-walk owner under the same neighborhood band is tighter now too: `0x0044c200`
  allocates a temporary `width*height` visit bitmap at `0x0062c128`, seeds one class-`2/4/5`
  starting cell, derives an initial direction index through the remap table `0x005ee5d4`, and then
  fans into the deeper recursive walker `0x0044be20`. That deeper walker widens dirty bounds
  `[world+0x21ad..+0x21b9]`, stamps one companion-word orientation lane through `0x005ee5cc`,
  reuses `0x00534ec0` plus `0x0044bdb0` to filter admissible neighbors, tracks temporary
  visitation in `0x0062c128`, and then applies the local byte-1 edge-bit `0x04/0x08` updates
  before returning. So the `0x0044bf9d..0x0044c422` cluster now reads as a real connected-component
  walk plus edge-flag refresh layer over the secondary raster rather than only a loose group of
  local neighbor counters. The adjacent mutation strip is tighter now too: `0x0044dcf0` refreshes
  companion-word bit `0x200` in one local rectangle by checking whether any neighbor belongs to
  class set `2/4/5`, while `0x0044df10` clears three local sidecar byte planes, demotes class `4`
  to `1` and class `5` to `3`, and then reruns that marked-bit refresh over the surrounding
  `+/-1` window. One level up, `0x0044e500` is the rect-wide owner that recomputes byte-1 edge
  bits `0x04/0x08` for class-`2/4/5` cells, dispatches `0x0044df10` on incompatible local
  patterns, and finally consumes the pending global seed pair at `[0x006d1304+0x78/+0x7c]`
  through `0x0044c200`. The shell-side owner of that pending pair is tighter now too:
  `[0x006d1304]` is the live `PaintTerrain.win` shell singleton while the callback-heavy side also
  keeps a second rooted pointer at `0x006d1334`; the tool constructor snapshots the broader
  terrain-paint state into both families while the world-side raster owner still only consumes
  `[0x006d1304+0x78/+0x7c]` as one pending component-seed pair. Its radial sibling `0x0044e7d0`
  is narrower:
  after validating world-space
  coordinates through `0x00414bd0`, it stamps class-`2` marks into the secondary raster by walking
  one clamped bounding box and admitting cells only when the radial falloff helper `0x0051db80`
  stays positive before re-entering `0x0044c570`. The two small support predicates under that same
  strip are now explicit too: `0x00414bd0` is the float grid-bounds gate, and `0x00449df0` is the
  integer rectangle clamp-and-validity helper shared by the local mutation owners. One level up,
  the broader rect-scoped owner is tighter now too:
  `world_rebuild_secondary_raster_derived_surface_and_companion_planes_in_rect` `0x0044e940`
  first reclamps the caller rectangle through `0x00449df0`, reruns the local edge-refresh owner
  `0x0044e500`, lazily ensures one presentation target through
  `0x0051f090/0x00534910/0x00534920/0x00534930`, and then resolves scaled target dimensions
  through `0x00534c50` before allocating one temporary `width*height` mask. Its main scan then
  walks the live secondary raster `[world+0x165d]` through the same class predicates
  `0x00534e10/0x00534e50/0x00534f00/0x00534ec0`: class-`1/3/4/5` cells force `0xff` into the four
  sidecar byte planes `[world+0x1631..+0x163d]`, while the broader per-cell pass writes packed
  values into the ensured target through `0x00534730` and also updates nibble lanes at byte offsets
  `+0x2` and `+0x5` inside the same three-byte secondary-raster cell family. After the publish it
  notifies the shell owner at `0x0062be68`, re-enters `0x00449f80` and `0x004881b0`, frees the
  temporary mask, expands the caller rectangle by dirty bounds `[world+0x21ad..+0x21b9]` through
  `0x00536710`, and finally seeds companion byte `[world+0x162d]` with `0xc4` on cells selected
  from mask plane `[world+0x1655]`. So the `0x0044e500 -> 0x0044e940` band is now a real
  derived-surface and companion-plane rebuild family rather than only a loose collection of local
  raster mutations. The local
  evidence now also supports a stronger negative conclusion: unlike `[world+0x1655]`, that second
  mask plane is not part of the actively rebuilt runtime overlay path, and in the grounded local
  corpus it behaves only as a separately seeded, cleared, and persisted sibling plane. One level
  lower, the
  base-plane allocator `0x00532c80` now reads more cleanly too: it is the narrower owner that
  clears `[world+0x15e1]`, optionally applies the current grid dimensions, allocates the base
  float-summary plane `[world+0x1605]`, the four sidecar byte planes `[world+0x1631..+0x163d]`,
  both one-byte mask planes `[world+0x1655/+0x1659]`, and the packed secondary raster
  `[world+0x165d]`, then seeds those planes with the same `0x02/0x01/0x00` default split. The
  load-side owner for those same planes is tighter now too: the constructor thunk `0x0044e910`
  immediately feeds the heavier payload body `0x0044cfb0`, which reads the rooted chunk families
  `0x2ee2/0x2ee3/0x2ef4/0x2ef5/0x2ef6/0x2ee4/0x2ee5/0x2f43/0x2f44`, allocates the core world-grid
  and secondary-raster arrays `[world+0x2129..+0x2141]` plus the route-entry collection
  `0x006cfca8`, initializes every grid-cell record through `0x0042ae50`, and only then hands off
  into `world_compute_transport_and_pricing_grid` `0x0044fb70`, the neighboring presentation
  refresh `0x00449f20`, and the shell-mode pulse `0x00484d70`. So the `0x0044e910 -> 0x0044cfb0`
  load side is now bounded as the heavy world-grid and secondary-raster bundle-load body rather
  than just another anonymous constructor tail. One
  level higher again, the broader world-presentation reinitializer `0x00537e60` now sits above
  that base allocator and the larger support-family ensure path `0x005375c0`: it stores the live
  grid dimensions, hard-resets the whole overlay runtime family through `0x00532590`,
  reinitializes the secondary-overlay family for those dimensions, and then republishes the
  neighboring overlay constants and support owners used by both the world-side reattach branch and
  the `.smp` restore-side presentation rebuild path, including several owners that all funnel
  through the shared static-template slot allocator `0x00532ad0` over the local `0x100` pointer
  band at `[world+0x08]`. Those neighboring owners are tighter now too: `0x00535070` is the small
  primary overlay-surface-or-template setup owner, while `0x005356e0` and `0x00535890` seed two
  larger static-template slot bands rooted at `[world+0x1568/+0x156c/+0x1574/+0x1578]` and
  `[world+0x1560/+0x1564]` respectively; the remaining heavier sibling `0x00535430` now reads as a
  shared four-slot overlay-surface rebuild owner that resamples one source or fallback descriptor
  into a short local slot strip above `[world+0x155c]`. The tail of that same reinitializer is
  tighter now too: after the larger support-family setup it seeds one seven-entry default overlay
  companion set through `0x005373b0`, whose inner allocator `0x00535950` populates the local
  `0x1b`-entry slot table from the static template rows `0x005dd300..0x005dd378`. The lifecycle
  side is tighter in the same way now: `0x00536044` is the shared teardown owner that frees those same
  three five-entry support families together with both mask planes, the packed secondary raster,
  the vector-byte planes, the local staging buffer, and the neighboring sidecar or coarse-cell
  tables. The remaining base-float lane is tighter too: the larger rebuild owner
  `0x00538360` now clearly writes one base float-summary field into `[world+0x1605]`, clears both
  one-byte mask planes, and then only repopulates the primary mask plane `[world+0x1655]` for the
  qualifying class-`1` interior cells before re-entering `0x00532d90` to normalize that base
  float-summary plane globally and `0x00532f60` to expand positive cells through one caller radius.
  That asymmetry is now enough to close the local semantic edge: `[world+0x1655]` is the actively
  rebuilt primary overlay mask, while `[world+0x1659]` is only the separately seeded and persisted
  secondary mask sibling with no comparably grounded distinct read-side consumer. The only grounded
  getter call to its root accessor `0x00533b60` is the shell staging branch at `0x00525bad`, and
  that branch immediately discards the returned pointer. The bundle side is now explicit too:
  `.smp` save-load treats the two mask planes as separate payloads with chunk ids `0x2cee` for
  `[world+0x1655]` and `0x2d51` for `[world+0x1659]`, while the neighboring `0x2d49/0x2d50`
  branches are the separate packed secondary-raster import lanes rather than alternate consumers
  of the second mask plane. So, in the mapped local code, `0x1659` is best treated as a persisted
  compatibility or seed-state sibling, not as a second actively consumed runtime overlay mask. The event
  side is tighter too:
  that `0x00433130` pass in turn materializes each live event record through
  `scenario_event_refresh_runtime_record_from_packed_state` `0x0042db20`. Current shell-side xrefs
  now tighten that event branch too: the first rebuilt linked row family under `0x0042db20` aligns
  with the standalone condition list later queried by `EventConditions.win`, while the second
  rebuilt family aligns with the four grouped effect lists later deep-copied through
  `scenario_event_clone_runtime_record_deep_copy` `0x0042e050` during event duplication and effect
  staging. The condition side is tighter now too: the tiny helper cluster
  `0x0042df30/0x0042df70/0x0042dfb0/0x0042dff0` is no longer just "some adjacent list scans".
  Current evidence bounds it as four predicates over the standalone `0x1e`-row condition list,
  testing class bits `0x01`, `0x02`, `0x04`, or any of those bits in the static table
  `0x005f3e04 + id*0x81`, with special fallback checks through event fields `[event+0x7f9]`,
  `[event+0x7fa]`, and `[event+0x7f0] == 0x63`. The shell side is tighter too: vtable slot
  `0x005d0cd8` now binds `shell_event_conditions_window_handle_message` `0x004d59e0`, and vtable
  slot `0x005d0cf8` binds `shell_event_effects_window_handle_message` `0x004d7060`. The effects
  side is tighter too: the lower helper trio is no longer anonymous. `0x004d5d00` now reads as the
  effect-type selector refresh under control family `0x4fb2`, `0x004d5f50` reads as the selected
  effect parameter-row repaint, `0x004d6090` is the heavier staged-effect editor refresh over the
  `0x4fc7/0x4fce/0x4ff6/0x4ff9/0x4ffc/0x5041/0x5044/0x5046/0x5047` bands, and `0x004d67f0`
  commits the current editor state back into the staged effect row at `[this+0x78]`. The verb side
  is tighter now too: `shell_open_event_conditions_modal_and_return_result` `0x004d9dc0` and
  `shell_open_event_effects_modal_and_return_result` `0x004d9e40` are the shared modal openers
  above the two editor windows; `0x004da640`, `0x004da700`, and `0x004d9ed0` now read as the add,
  edit, and remove verbs for standalone condition rows; `0x004da7c0`, `0x004da860`, and
  `0x004da920` are the matching add, edit, and remove verbs for grouped effect rows; and
  `0x004d8120` is now the heavier condition-row list panel refresh those condition-side verbs
  re-enter after mutation. The conditions-side refresh split is tighter too: `0x0042d700`
  aggregates standalone condition-list class or modifier flags, `0x0042d740` aggregates grouped
  effect-row type flags for one selected grouped list, `0x004d9970` owns the condition-class
  summary and grouped-row status bands, `0x004d77b0` owns the grouped summary-band affordance gate
  for `0x4fed..0x4ff0` when selector `0x5000` lands on `0x5002`, `0x004d9d10` owns the smaller
  grouped-effect territory-target affordance on control `0x500b`, `0x004d9f50` owns the selected-event mode
  strip and summary text panels, and `0x004d9390` is the mode-dependent detail-row switch beneath
  that strip. `0x004da0f0` is tighter too: selector `0x5001` now has the strongest current
  RT3.lng fit as the condition-side `Test against...` mode above `0x004d9970`, while selector
  `0x5002` has the strongest current fit as the grouped-effect-side `Apply effects...` mode.
  That `0x5002` branch now clearly builds control `0x5014` from RT3.lng `1160..1164` as `to the
  company/player/player (i.e. chairman)/territory for which the condition is TRUE` before
  enabling the adjacent `0x5005`, `0x500a`, and `0x5014..0x501c` family. The strongest current
  RT3.lng fit for the remaining visible target-scope strip is now `0x5015 = to the whole game`,
  `0x5016..0x5018 = to all/human/AI companies`, `0x5019 + 0x500b = to territories`, and
  `0x501a..0x501c = to all/human/AI players`; the grouped effect-row type mask matches that split
  directly through bits `0x08`, `0x01`, `0x04`, and `0x02`. The
  selected-event strip is tighter now too: `0x004db120` is the broader selected-event repaint and
  navigation refresh above those smaller helpers, `0x004db520` and `0x004db5e0` are the previous
  and next selected-event stepping verbs, `0x004db8b0` is the add-or-clone event modal helper,
  `0x004dba90` is the rename verb, `0x004d9360` is the delete verb, `0x004db6a0` is the live
  selected-event id setter behind control `0x4e84`, and `0x004db6f0` is the callback-binding plus
  pending-selection bootstrap path that seeds the strip during window bring-up. The larger
  dispatcher at `0x004dbb80` now makes the strip explicit: `0x4e85..0x4e8a` are previous, next,
  add blank, clone selected, rename, and delete event, while the later grouped band commits current
  summary state through `0x004d8d50` before changing grouped selector `[this+0x9c]` via `0x004dbf93`.
  The selection bootstrap side is tighter too: `0x004daf40` is now the placeholder reset helper for
  the selected-event summary controls `0x4eaf`, `0x4eac`, `0x4ed9`, `0x4edb`, and `0x4fdf..0x4fe2`.
  The grouped target-scope side is tighter too: `0x004d8ea0` now reads as the commit helper for current
  selected-event text panels before selection or grouped-action changes, `0x004d8d50` now records
  the hidden selector family `0x5006..0x500e -> 0..8`, and `0x004dab60` projects that ordinal
  one-to-one onto the visible grouped-effect target-scope display strip `0x5014..0x501c`. That
  split is firmer now: `0x5006..0x500e` are the canonical hidden selectors that get stored into
  `[event + group + 0x7fb]`, while `0x5014..0x501c` are the visible mirror rows republished from
  that same ordinal rather than a second independently named selector family. The grouped row and
  stored-summary refresh side is tighter too: `0x004d88f0` is now the selected grouped-effect
  row-list renderer for `0x4ed5`, formatting the grouped `0x28`-byte rows through RT3.lng
  `1154..1159`, and `0x004da9a0` is the current grouped-summary-state republisher that reloads
  `0x500a`, `0x500b`, and visible action selection `0x5014..0x501c` from `[event + group + ...]`
  before tailing back into `0x004da0f0`,
  `0x004dbfca` as the grouped target-scope mode selector that persists the chosen control id into
  `0x00622074`, with `0x5001/0x5002` now strongest-fit as `Test against...` and
  `Apply effects...`, `0x004dbeeb` as the pending shared summary-text triplet publish helper for
  `0x4eac/0x4ed9/0x4edb`,
  `0x004d91e0` as the selected-event summary-header and grouped-mode commit helper above
  `0x004d8d50`, and `0x004dbe7a` as the narrower `0x4ec6/0x4ec7` choice-event single-player-only
  warning modal branch rooted at RT3.lng `3887`. The remaining gaps on
  this lane are narrower again because the grouped-band `0x4dc09c` table now closes one earlier
  overclaim: controls `0x5001/0x5002` are the only `0x4fed..0x501c` entries that route into
  `0x004dbfca` on the `0xcf` side, while visible rows `0x5014..0x501c` only route to the smaller
  `0x004d9d10` affordance path and the rest of `0x4ff1..0x5013` are default no-ops. The open
  question is therefore no longer whether those visible target-scope rows are direct selector verbs;
  current evidence says they are not.
  The local slot records are rooted at
  `[world+0x69d8]`,
  `[slot+0x01]` polarity and the external role gate at `[world+0x0bc3+slot*9]` are now grounded, and
  `[slot+0x03]` now looks like the distinguished primary-human-seat marker because current grounded
  writes seed it only on slot zero and later logic moves it solely by whole-record compaction. The
  open question is no longer whether the seeded trio lands in the visible shell company roster;
  current evidence says it does, and ordinary `Start New Company` now looks like a fresh-company
  allocator through `start_new_company_dialog_commit_create_company` and
  `start_new_company_request_create_company`, not like the path that claims one of the seeded named
  railroads. The immediate post-roster station branch is now clearly separate: current grounded
  resource names and handlers put mode `8` on `StationDetail.win`, mode `5` on `StationList.win`,
  and the subordinate selector helper on `StationPick.win`. The company-side ownership question has
  therefore moved down a layer rather than staying open. We now have a recovered `CompanyDetail.win`
  owner family through `shell_company_detail_window_refresh_controls`,
  `shell_company_detail_window_construct`, and `shell_company_detail_window_handle_message`; the
  same owner now has one broader bounded read-side lane too, because control `0x9470` uses
  `shell_company_detail_render_financial_history_panel` to draw the five-step Revenue or Expenses or
  Interest or Profit or Lifetime strip, sibling control `0x9471` reuses
  `shell_format_company_financial_summary_card` through
  `shell_company_detail_render_company_summary_card`, controls `0x947d` and `0x947e` now ground a
  bond maturity and repay panel through `shell_company_detail_render_bond_maturity_and_repay_panel`,
  control `0x9488` now grounds the debt or credit or rate summary block through
  `shell_company_detail_render_debt_credit_and_rate_summary_panel`, control `0x948a` now grounds the
  share-value and dividend-payout block through
  `shell_company_detail_render_share_value_and_dividend_summary_panel`, while the broader six-row
  per-share stock-data family is now bounded under `shell_format_company_stock_data_panel`, and the
  adjacent territory selector lane is bounded through
  `shell_company_detail_select_territory_access_row`,
  `shell_company_detail_render_territory_access_row`,
  `shell_company_detail_sync_selected_territory_from_picker`, and
  `shell_company_detail_refresh_selected_territory_access_summary`; the first finance-action layer
  beneath it is bounded through the bond, stock-issue, stock-buyback, and dividend-rate helpers; the
  territory-access side is bounded too through
  `shell_company_detail_refresh_selected_territory_access_summary`,
  `shell_company_detail_buy_territory_access_rights_flow`, and the underlying company access-rights
  helpers; and the full takeover and merger vote-result lane is now grounded through
  `shell_resolve_chairmanship_takeover_vote_and_commit_outcome`,
  `shell_present_chairmanship_takeover_vote_outcome_dialog`,
  `shell_resolve_merger_vote_and_commit_outcome`, and `shell_present_merger_vote_outcome_dialog`.
  The remaining company-side uncertainty is therefore narrower than before: the broader support and
  valuation side is now tighter too because
  `company_compute_cached_recent_per_share_performance_subscore`,
  `company_compute_five_year_weighted_shareholder_return`, and
  `company_compute_public_support_adjusted_share_price_scalar` bound the recent per-share
  performance and investor-support/share-price blend beneath those vote resolvers; the recent
  per-share feeder now has a grounded four-lane tail too, with current partial-year weight
  `(5 * [world+0x0f]) - 5`, prior full-year weights `48/36/24/12` on `0x1f/0x1e`, dividend
  non-decline pair weights `9/8/7/6` on `0x20`, lane weights `40/10/20/30`, the startup age ramp
  `0/0/0/100 -> 25/25/35/100 -> 50/50/65/100 -> 75/75/85/100 -> 100/100/100/100`, a strongest-lane
  `*1.25` boost, a weakest-lane `*0.8` reduction, and separate bounded-intermediate versus final
  difficulty applications under `0x005f33b8`; the next consumer `0x00424fd0` is also tighter now,
  with the young-company interpolation against `[company+0x57]`, caller pressure clamped to
  `[-0.2, 0.2]`, one `(shares / 20000)^0.33` share-count growth term, and the later threshold
  ladder `0.6 / 0.45 / 0.3 / 1.7 / 2.5 / 4.0 / 6.0` before the issue-`0x37` multiplier,
  `scenario_state_compute_issue_opinion_multiplier` now bounds the
  next layer of optional company, chairman, and territory-specific opinion overrides on the active
  scenario state, and the broader stat-reader family around
  `company_read_control_transfer_metric_slot` and
  `company_read_year_or_control_transfer_metric_value` is no longer just a merger-premium helper.
  Current grounded callers show the same metric family feeding the annual shareholder-revolt and
  creditor-liquidation lane surfaced by localized ids `300..304`, while the debt-side shell and
  bond lane now separately close `0x38` as `Credit Rating` and `0x39` as `Prime Rate`. That means
  the remaining gap is now mostly gone on the UI side too: issue `0x37` is already bounded to the
  same investor-confidence family as the equity-support and governance-pressure paths, and current
  grounded UI evidence still stops at the investor-attitude sentence family rather than one
  standalone caption. The calendar side is tighter now too:
  `[world+0x15]` is the absolute counter for the same mixed-radix `12 x 28 x 3 x 60`
  year-plus-subfield tuple packed by `0x0051d3c0` and unpacked by `0x0051d460`, not just a vague
  “calendar-like” blob. The `TrackLay.win` family now clearly owns `Lay single track.` `Lay double track.`
  and `Bulldoze` as its three primary modes, its bridge selector, its wrapped frequency preferences,
  and a strongly aligned pair of `Auto-Hide Trees During Track Lay` and `Auto-Show Grade During
  Track Lay` toggles; the `StationPlace.win` family now clearly owns its six top-level category
  buttons, the station-style scroller, and the station-rotation controls. The older `Building
  placement center` string 671 no longer looks like a live StationPlace control label in the current
  recovered flow, because the active constructor, preview, refresh, and dispatcher paths all use
  neighboring ids such as 669 and 2208 without a direct recovered lookup of 671. On save or load the
  broad serialize-versus-restore split is now grounded, the non-Quicksave `.gmp/.gmx/.gmc/.gms`
  families are separated, and the auxiliary `.gmt` path is at least bounded to the preview-surface
  side owner. The higher-value shell-facing gap has therefore shifted upward to the remaining
  semantics of the post-load generation phases, the later recurring structure-population cadence,
  the deeper vote-weight formulas inside takeover and merger resolution, and the still-open meaning
  of the packed simulation calendar tuple.

- CompanyDetail, tighter section ownership: the shell detail family now has an explicit
  section-selector lane in addition to the read-side panels already mapped. Controls
  `0x9472..0x9475` directly select the four visible CompanyDetail sections through `0x006cfe60`,
  `0x9476..0x9479` are the companion visual controls for that same tab strip, and section `0` is now
  bounded more tightly as the chairman or governance slice around the portrait-backed chairman band
  on `0x9480` plus the dynamic overview widget `0x947f`. That widget is no longer just a vague
  status line: the section-0 refresh binds it through a dedicated stack-built dynamic text path,
  and the strongest current shared formatter candidate is
  `shell_format_company_governance_and_economy_status_panel` at `0x004e5cf0`, which first renders a
  five-line company-metric preamble through localized ids `1211..1215`: `Revenues` from slot
  `0x2c`, `Profits` from slot `0x2b`, `Load miles hauled` from slot `0x17`, `Revenue per load
  mile` from the derived `slot 0x2c / slot 0x17` branch, and `Average speed` from slot `0x26`
  rendered through `1216` `%1 m.p.h.`. It then splits the governance summary more concretely: no
  linked chairman emits `3045`, wholly owned companies emit `3046` for the scenario-selected
  chairman or `3047` for another linked chairman, and investor-owned companies emit the
  investor-attitude lines `3048/3049` with one adjective from the table at `0x00622170`. That
  branch is no longer using unnamed helpers either: `company_get_linked_chairman_profile_record`
  `0x00426ef0` resolves the linked chairman profile and `chairman_profile_owns_all_company_shares`
  `0x004768c0` is the full-ownership test behind the `3046/3047` split. The salary side is tighter
  too: the formatter computes one signed delta from `[company+0x14f]` and `[company+0x0d59]`, then
  chooses `3050..3052` for the scenario-selected chairman or `3053..3055` for another linked
  chairman depending on whether that delta is negative, positive, or zero. The bonus line is
  narrower still: it only appears when the display year matches `[company+0x34f]`, using amount
  `[company+0x353]` with `3056` or `3057`. It then appends the
  `1218` `Economy status - %1.` tail caption and stages the adjacent selected-company report or
  list help-title pairs `1219/1220` `Income Statement`, `1221/1222` `Balance Sheet`,
  `1223/1224` `Haulage Report`, `1225/1226` `Stock Report`, `1227/1228` `Train List`,
  `1229/1230` `Station List`, `1231/1232` `Industry List`, and `1233/1234` `Cargo List`.
  Current evidence still does not recover separate `CompanyDetail.win` action controls for that
  strip under `shell_company_detail_window_handle_message`, so it currently reads as staged
  overview text or help content rather than as a closed launcher family. The direct `0x947f`
  formatter call is still indirect, but the widget boundary is tighter too: the generic shell
  helpers `shell_control_refresh_matching_dynamic_text_payload` `0x00540a47` and
  `shell_control_release_dynamic_text_payload` `0x005639d2` now show that type `0x6f` controls
  free or swap one heap-backed text payload and then short-circuit as a special dynamic-text case,
  which strengthens the reading of `0x947f` as a display-only overview widget rather than a normal
  callback control. One adjacent boundary is tighter now too: the broader overview wrapper at
  `shell_render_company_overview_panel_header_and_optional_change_affordance` `0x004e5a80` owns
  the fallback no-company texts `1210`, `3043`, and `3888`, styles controls `0x3f06` and `0x3f07`,
  and on the narrower selected-company branch appends `3044` `Click to change company name and
  logo.` plus the neighboring `1941` `Change` affordance before falling through into the shared
  `0x004e5cf0` text body. That keeps the name/logo affordance outside the ordinary
  `CompanyDetail.win` action dispatcher and makes the `0x947f` alignment cleaner. The message-side
  action band is tighter too: `0x94b5` grounds
  territory-access purchase, `0x94b6` grounds bankruptcy, `0x94cf..0x94d2` ground bond issue, stock
  issue, stock buyback, and dividend-rate changes, `0x9493` routes into the destructive
  company-clear helper that deactivates the selected company and clears chairman/share links,
  `0x94d6` grounds bankruptcy, `0x94d7..0x94da` ground bond issue, stock issue, stock buyback, and
  dividend-rate changes, `0x94db` grounds merger, `0x94dc` grounds resignation, and `0x9538` grounds
  chairmanship takeover. The finance-side dialog family is tighter too: the bond-issue lane now has
  the dedicated modal renderer `shell_company_detail_render_issue_bond_offer_dialog` `0x004c3560`
  for underwriter terms `968..972`, the stock-issue lane has
  `shell_company_detail_render_issue_stock_offer_dialog` `0x004c3b50` for the staged offer lines
  `975..978`, and the buyback lane has
  `shell_company_detail_render_stock_buyback_offer_dialog` `0x004c4300` for broker lines
  `981..984`. The compact summary card on sibling control `0x9471` is tighter too:
  `shell_format_company_financial_summary_card` at `0x004bfb30` now clearly renders `Cash:`,
  `Revenue:`, and `Profits:` from company slots `0x0d`, `0x2c`, and `0x2b`, rather than one looser
  unnamed finance block. The dividend lane is now split the same way:
  `shell_company_detail_setup_dividend_rate_adjust_controls` `0x004c4c70` binds the paired adjust
  controls `0x99e8` and `0xc0f9`,
  `shell_company_detail_render_change_dividend_rate_dialog` `0x004c4e30` renders localized ids
  `988..990`, and
  `shell_company_detail_handle_change_dividend_rate_dialog_message` `0x004c5140` clamps the staged
  dividend rate against `company_compute_board_approved_dividend_rate_ceiling` `0x00426260` and
  raises localized id `991` when the board refuses a higher dividend, all before the existing
  company commit path. All four finance verbs now converge through the shared
  callback-driven modal opener `shell_open_custom_modal_dialog_with_callbacks` `0x004c98a0`, which
  is also reused by the multiplayer staged text-entry lane. The front controls in section `0` are
  tighter too: `0x948b` is a
  tutorial-guarded escape or back control that shows localized id `3724` `This option is disabled in
  the tutorial.` before falling back to the shell detail-manager escape path, `0x9491` and `0x9492`
  only restyle the paired visuals `0x948f` and `0x9490`, and `0x9494` opens localized id `3635`
  `Enter the amount that your company's cash should be` and writes the accepted value directly into
  the selected company cash pair. The neighboring debt section is tighter now too: controls
  `0x947d` and `0x947e` no longer read as one-off bond widgets, but as the owners of two repayable
  bond-slot row bands, `0x94e8..0x950f` and `0x9510..0x9537`. Those row controls now clearly
  converge on the same repayment path in the message dispatcher: they reject unaffordable repayment
  through localized id `2990`, open the early-repayment confirmation rooted at `2991`, and then
  either commit through `company_repay_bond_slot_and_compact_debt_table` `0x00423d70` or package
  the request through the multiplayer shell transport. The render-side owner is tighter too:
  `shell_company_detail_render_bond_maturity_and_repay_panel` formats `Due %1` and `Repay this
  bond.` for the selected debt slot while the tiny binder
  `shell_company_detail_bind_bond_row_band_for_active_panel` switches between the two row bands.
  Current `0xcb` dispatch does not treat `0x948f`, `0x9490`, `0x94d4`, or `0x94d5` as standalone
  action cases. The message-side jump table now makes that passive/action split explicit too: in the
  dispatch byte map rooted at `0x004c6640`, controls `0x94d6..0x94dc` map to cases `0x06..0x0c`,
  control `0x9538` maps to case `0x0d`, and the neighboring companion rows `0x94d4` and `0x94d5`
  stay on the default path. The refresh-side ownership is tighter too: the helper now explicitly
  loops over `0x94d4..0x9537` as the selected-company-owned band and over `0x9538..0x959b` as the
  linked-chairman-owned band, and those two loops do not use the same style polarity.
  `0x94d4..0x9537` take style `0x65` when the selected company matches the scenario-selected
  company and `0x87` when it differs, while `0x9538..0x959b` take style `0x87` when the selected
  company's linked chairman matches the scenario-selected chairman and `0x65` otherwise. The
  selected-company action side
  is tighter now too: scenario toggle `0x006cec78+0x4a8f` re-enables bankruptcy `0x94d6` together
  with passive companion row `0x94d4`, `+0x4a8b` re-enables issue bonds `0x94d7` together with
  passive companion row `0x94d5`, `+0x4a87` re-enables stock issue and stock buyback
  `0x94d8..0x94d9`, `+0x4a93` re-enables dividend `0x94da` together with the same passive
  companion row `0x94d5`, `+0x4adb` re-enables merger `0x94db`, `+0x4acb` re-enables resignation
  `0x94dc`, and `+0x4acf` re-enables chairmanship takeover `0x9538`. That makes `0x94d4/0x94d5`
  read more like passive companion or heading widgets than hidden verbs. The constructor boundary
  is tighter too: current `CompanyDetail.win` setup still only binds explicit callbacks for
  `0x9470`, `0x9471`, `0x947d`, `0x947e`, and `0x948c..0x948e`, not for the wider section-0 row
  bands. That keeps the remaining `0x94d4..0x959b` content looking more like resource-defined
  display rows that are gated and restyled by refresh than like individually code-rendered widgets.
  That leaves the main remaining CompanyDetail-specific shell edge at the exact `0x947f` formatter
  binding plus the still-unsplit render-side governance rows inside `0x94d4..0x959b`.
- Adjacent `LoadScreen.win` report family: the neighboring shell lane around controls
  `0x3ef6..0x4073` is now separated from `CompanyDetail` instead of being treated as one more
  extension of the `0x947f` overview path. The real outer owner is
  `shell_load_screen_window_construct` `0x004ea620`, which binds `LoadScreen.win`, randomizes the
  `LoadScreen%d.imb` background family, stores the singleton at `0x006d10b0`, and seeds the first
  visible page-strip controls. Above the older page-specific work, the real message owner is now
  `shell_load_screen_window_handle_message` `0x004e3a80`: it owns page id `[this+0x78]`,
  page-local substate `[this+0x7c]`, page-kind `[this+0x80]`, current company `[this+0x88]`,
  current chairman profile `[this+0x8c]`, display year `[this+0x9c]`, and the page-local report
  row latch `[this+0x118]`, then fans back into the shared selector
  `shell_load_screen_select_page_subject_and_refresh` `0x004e2c10`, the company-step helper
  `0x004e3a00`, and narrower page branches such as `0x004e45d0`. The matching render-side owner is
  now bounded too: `shell_load_screen_render_active_page_panel` at `0x004ea060` formats the common
  heading and panel frame, then switches on page id `[this+0x78]` and hands control down into the
  active page body. That older branch is now demoted to what it actually is:
  `shell_load_screen_profile_stock_holdings_page_handle_message`, the page-specific handler beneath
  the stock-holdings slice. Inside that same family,
  `shell_load_screen_render_profile_stock_holdings_summary_panel` at `0x004e5300` grounds the
  selected-profile holdings page: it resolves the current chairman profile from `[this+0x8c]`,
  renders the top summary rows `1204` `Stock Value:`, `1205` `Total Assets:`, and
  `1206` `Stock Holdings:`, then walks the active company roster and formats one row per positive
  holding through `1201` `Click to view details on %1.`, `1207` `%1 Shares`, and `1208` `%1 Value`,
  falling back to `1209` `None` when no positive holdings survive. It also appends `3029`
  `Click to change player name and portrait.` plus the adjacent `1941` `Change` affordance only
  when the rendered profile matches the scenario-selected chairman. The earlier pages are tighter
  now too: `0x004e68e0` is the selected-company financial ranking page using the active company
  roster plus `1235..1245` for revenue, profit, cash, track mileage, and report affordances; and
  `0x004e6ef0` is the active-chairman wealth ranking page using the chairman profile collection
  plus `1237`, `1241`, `1246..1250` for cash, stock, total, and purchasing-power style comparisons.
  The later sibling renderers are broader than that one holdings page now too: `0x004e7670` is the
  selected-company train list page using `1235..1267`, `0x004e8270` is the selected-company
  building list page using `1268..1278`, `0x004e8bb0` is the selected-company station list page
  using `1279..1288`, and `0x004e9460` is the map-wide cargo list page using `1289..1298` over the
  live candidate collection rather than one company roster. The last broad early-page owner is
  tighter now too: `0x004e9b20` is the shared multi-year company report-table renderer for page
  `4` `Income Statement`, page `5` `Balance Sheet`, and page `6` `Haulage Report`, all driven from
  `0x004ea060` with one caller-supplied mode byte and yearly company rows built through
  `company_read_year_or_control_transfer_metric_value`. The row families are bounded too:
  income-statement rows `1301..1315`, balance-sheet rows `2816` and `1317..1322`, and
  haulage-report rows `1323..1335`. The only special rows inside that family are now tighter too:
  `0x00425880` and `0x004258c0` provide the negative-cash and positive-cash interest-rate inserts
  for the `%1/%2` placeholders in strings `2815` and `2816`, so they are no longer anonymous
  private math blobs. The adjacent early siblings are tighter now too: `0x004e5130` is the
  selected-company `Stock Data` page wrapper that falls back through `1299` and otherwise reuses
  `0x004c0160` to render the `Largest Shareholders`, `Shares`, and `Per Share Data` family;
  `0x004e6ef0` is the `Player List` page; `0x004e5300` is the `Player Detail` holdings page; and
  `0x004e51ea` is the `Game Status` briefing panel that pulls current scenario briefing text from
  the live scenario text store and appends the `1772/1773` `Briefing` affordance. The active-page
  renderer at `0x004ea060` is now tighter too because its 13-byte page descriptor table at
  `0x006220a0` has been decoded directly as `{ page kind, title string id, `0x3ef8` backlink
  page, selected-company-header flag }`. The currently grounded rendered title order is:
  `XXX`, `COMPANY OVERVIEW`, `COMPANY LIST`, `INCOME STATEMENT`, `BALANCE SHEET`,
  `HAULAGE REPORT`, `STOCK DATA`, `PLAYER LIST`, `PLAYER DETAIL`, `GAME STATUS`,
  `TRAIN LIST`, `TRAIN DETAIL`, `STATION LIST`, `STATION DETAIL`, `CARGO LIST`,
  and `INDUSTRY LIST`. Its live body bindings are now bounded too: page `0` falls back to
  `1203` `Unable to display page`, page `1` is the company overview wrapper, page `2` is the
  company list page, pages `3..5` are income statement, balance sheet, and haulage report, page
  `6` is stock data, page `7` is player list, page `8` is player detail, page `9` is game status,
  page `0x0a` is train list, page `0x0b` currently falls back to `1203`, page `0x0c` is station
  list, page `0x0d` currently falls back to `1203`, page `0x0e` is cargo list, and page `0x0f`
  is industry list. The row-click path is tighter now too: player-list rows re-enter page `8`
  directly, but train, station, and industry rows leave `LoadScreen.win` through the shell
  detail-panel manager at `0x004ddbd0` instead of switching to title-table pages `0x0b` or
  `0x0d`. Page `0` is tighter now too: its descriptor is kind `0`, title `1200` `XXX`, backlink
  `0`, and header flag `0`, and no current post-constructor selector path has been recovered for
  it. The descriptor side now also bounds the only known reverse route for the dormant detail
  titles: `0x3ef8` is the table-driven backlink affordance, so if page `0x0b` or `0x0d` were ever
  selected, the known reverse path would return to train-list page `0x0a` or station-list page
  `0x0c` respectively rather than through a separate detail-only owner.
  The launcher side is tighter too: current grounded `shell_open_or_focus_load_screen_page`
  callers cover pages `1`, `2`, `3`, `4`, `5`, `6`, `7`, `9`, `0x0a`, `0x0c`, `0x0e`, and `0x0f`,
  and no current recovered opener or row-click route selects `0x0b` or `0x0d`. So the
  `LoadScreen.win` family now has a much cleaner shape: one outer message owner
  `0x004e3a80`, one active-page render owner `0x004ea060`, and then the narrower page-specific
  handlers and renderers beneath them. The launcher side is tighter now too: `0x004e4ee0` is the
  shared open-or-focus ledger-page owner above this family. Outside sandbox it either re-enters
  `shell_load_screen_select_page_subject_and_refresh` on the live runtime at `0x006d10a8` or
  allocates that transient runtime, seeds it through `0x004e4b10`, and enters the visible modal
  loop; inside sandbox it raises localized id `3899` `The ledger is not available in sandbox mode.`
  instead. That narrows the remaining `LoadScreen.win` gap again: `TRAIN DETAIL` and
  `STATION DETAIL` now read as dormant title-table entries unless some still-unrecovered nonstandard
  selector reaches them. The live auto-load boundary is tighter now too: hook-driven
  `shell_transition_mode(4, 0)` now completes old-mode teardown, reconstructs and republishes
  `LoadScreen.win`, and returns cleanly, but the later post-transition service ticks still keep
  `[0x006cec78] = 0`, `[shell_state+0x0c]` on the same `LoadScreen.win` singleton, and
  `[LoadScreen.win+0x78] = 0` through at least counts `2..8`. So the next runtime edge is no
  longer the old mode-`4` teardown or publish band; it is the `LoadScreen.win` message owner
  `0x004e3a80` itself, because later service alone is not promoting the plain load screen into the
  separate startup-runtime object path. One later runtime probe did not actually reach that edge:
  the `0x004e3a80` hook installed, but the run never produced any ready-count, staging,
  transition, post-transition, or load-screen-message lines, only ordinary shell node-vcall
  traffic. So that result is now treated as a gate-or-cadence miss rather than as evidence against
  the `LoadScreen.win` message path itself. The newer shell-state service trace tightens it again:
  on a successful staged run the later service ticks do execute in `mode_id = 4`, but the
  `0x004e3a80` message hook still stays silent while the state remains frozen in the plain
  `LoadScreen.win` shape. So the next runtime boundary is now the shell-runtime prime call
  `0x00538b60` beneath `shell_state_service_active_mode_frame` `0x00482160`, not the message owner
  alone. The first direct `0x00538b60` probe run is not trustworthy yet, though: it stopped
  immediately after the first shell-state service-entry line, before any ready-count or
  runtime-prime entry logs. So that result is currently treated as probe validation work, not as a
  real boundary move inside RT3. The static service branch is conditional too: `0x00482160` only
  enters `0x00538b60` when `[shell_state+0xa0] == 0`, so silence from the runtime-prime hook does
  not yet prove the shell stops before that call unless the service-entry logs also show the `+0xa0`
  gate open. The newer run now closes that condition: `[shell_state+0xa0]` is `0`, and the
  `0x00538b60` runtime-prime hook enters and returns cleanly. The newer run closes the next owner
  too: `0x00520620` `shell_service_frame_cycle` also enters and returns cleanly on the same frozen
  mode-`4` path, and the logged fields match its generic branch rather than a startup-promotion
  lane (`[+0x1c] = 0`, `[+0x28] = 0`, `flag_56 = 0`, `[+0x58]` pulsed then cleared, and
  `0x006cec78` stayed `0`). So the next runtime boundary under the same shell-state service pass is
  now one level deeper: the per-object service walker `0x0053fda0` beneath `0x00538b60`. The newer
  run closes that owner too: it enters and returns cleanly while servicing the `LoadScreen.win`
  object itself, with `field_1d = 1`, `field_5c = 1`, and a stable child list under
  `[obj+0x70/+0x74]`, and its first child-service vcall target at slot `+0x18` stays
  `0x005595d0`. Since `0x006cec78` still stays `0` through those clean object-service passes, the
  next runtime boundary is now the child-service target `0x005595d0`, not the higher object
  walker. The newer child-service run narrows that again: the first sixteen `0x005595d0` calls are
  stable child lanes under the same `LoadScreen.win` parent, with `[child+0x86]` pointing back to
  the load-screen object, `field_b0 = 0`, and a split where earlier children carry
  `flag_68 = 0x03` and return `4` while later siblings carry `flag_68 = 0x00` and return `0`. The
  static body matches that read too: `0x005595d0` is gated by `0x00558670` and then spends most of
  its work in draw or overlay helpers `0x54f710`, `0x54f9f0`, `0x54fdd0`, `0x53de00`, and
  `0x552560`, so it now reads as another presentation-side service lane rather than the missing
  startup-runtime promotion. The widened allocator-window trace then reconciled the runtime with
  the static mode-`4` branch one step further: the first transition-window allocation is `0x7c`,
  which matches the static pre-construct `0x48302a -> 0x53b070` alloc exactly, and the later
  `0x111/0x84/0x3a/0x25...` allocations all occur before `LoadScreen.win` construct returns, so
  they now read as constructor-side child or control setup. That means the allocator probe did not
  disprove the still-silent startup-runtime slice; it simply exhausted its log budget inside the
  constructor before the post-construct block. The later reset-at-return run is now the decisive
  one: after `LoadScreen.win` construct returns there are still no further allocator hits before
  publish and transition return, which matches the corrected jump-table decode because mode `4`
  does not own the `0x46c40 -> 0x4336d0 -> 0x438890` startup-runtime path.
- Editor breadth: the broader map-editor page owner is now bounded through
  `map_editor_panel_select_active_section` `0x004ce070` and
  `map_editor_panel_dispatch_active_section_message` `0x004cf700`, which switch among the grounded
  setup pages, `Cities/Regions`, `Territories`, the `Players` and `Player Pool` setup slices, the
  now-grounded `Building Density` page, the locomotives-available and industry-availability pages,
  the economic and special-condition pages, the `Port/Warehouse Cargos` page, and the later report
  pages. The mid-editor ownership is materially clearer now too: the chairman-slot editor is the
  `Players` page, the available-chairman editor is the `Player Pool` page, and the former unnamed
  dual tri-state page now lines up with localized page text `997` `Building Density` plus help text
  `1017` and the direct field captions `1642` `Starting Building Density Level:` and `1644`
  `Building Density Growth:`. Both controls are now bounded as stored ordinal bytes `0/1/2` rather
  than loose labels: the first three-choice control is the map-wide starting-density selector, with
  its default middle state `1` matching the documented `100%` baseline from `1643`; the second is
  the paired overall growth selector whose effects later appear in the city-growth side of the
  simulation. `map_editor_city_region_panel_construct` and
  `map_editor_city_region_panel_handle_message` own the city-or-region editing lane with rename and
  copy-industry-data flows. That copy side is tighter now too: the handler first enters
  `0x00420e00`, which rebuilds the selected region's profile collection `[region+0x37f]`, clones
  the source region's live label-weight entries when a source region is present, and otherwise
  reseeds a fixed default weight set through repeated `0x004206b0` calls. The no-source companion
  `0x00420ed0` now makes that split explicit: it rebuilds the same subcollection and then picks one
  of two fixed default label-weight sets based on region class dword `[region+0x23e]`, using one
  all-`0.2f` family for nonzero-class regions and one class-`0` family that starts with `0.3f`
  before continuing with repeated `0.2f` entries. The lower mutator
  `0x004206b0` then linearly scans the selected region subcollection by profile label, creates a
  new profile only when the copied weight is positive, removes an existing profile when the copied
  weight is non-positive, updates `[entry+0x1e]` otherwise, and refreshes the region's derived
  availability-summary bytes `[region+0x2f6/+0x2fa/+0x2fe]` through `0x00420410`; `map_editor_territory_panel_construct` and
  the adjacent no-source companion `0x00420ed0` is tighter too: it rebuilds the same collection
  root `[region+0x37f]` but then seeds one of two fixed default profile-label sets directly through
  repeated `0x004206b0` calls, splitting by region class dword `[region+0x23e]`. Nonzero-class
  regions take one all-`0.2f` default set, while class-0 regions take a different set that starts
  with one `0.3f` weight before continuing with repeated `0.2f` entries. That makes `0x420ed0`
  the true class-split default-profile companion to the source-cloning helper at `0x420e00`,
  rather than just more of the same editor copy path.
  `map_editor_territory_panel_construct` and
  `map_editor_territory_panel_handle_message` own the territory rename and border-remap lane;
  `map_editor_locomotive_availability_panel_construct` plus
  `map_editor_locomotive_availability_panel_handle_message` now bound the locomotive policy page
  over `0x006ada84`; `map_editor_industry_availability_panel_construct` plus
  `map_editor_industry_availability_panel_handle_message` do the same for the industry candidate
  pool at `0x0062b268`; and `map_editor_port_warehouse_cargo_panel_construct` plus
  `map_editor_port_warehouse_cargo_panel_handle_message` now ground the recipe-book page that edits
  port or warehouse cargo policies through twelve per-book state blocks at
  `[0x006cec78+0x0fe7+index*0x4e1]`. Each book now has a shared maximum annual production float at
  `book+0x3ed` and five fixed cargo-line entries starting at `book+0x3f1` with stride `0x30`; each
  line is bounded as a mode dword, annual amount, a supplied-cargo token at `+0x08`, and a
  demanded-cargo token at `+0x1c`. The constructor and handler now make those fields materially
  tighter too: the row pair shown in `Supply Only` and `Production Demand->Supply` is the `+0x08`
  supplied-cargo selector, the row pair shown in `Demand Only` and `Production Demand->Supply` is
  the `+0x1c` demanded-cargo selector, and the single amount field at `+0x04` is labeled `Annual
  Demand:` only in mode `1` but `Annual Supply:` in modes `2/3`. The stronger new runtime-side
  result is now a full chain rather than only the importer:
  `scenario_state_rebuild_port_warehouse_cargo_recipe_runtime_tables` first imports those same five
  lines into one repeated array of identical `0xbc`-byte runtime descriptors with no row-index
  special casing, and the candidate-side rebuild pass at
  `structure_candidate_collection_rebuild_runtime_records_from_scenario_state` `0x00412d70` then
  projects those descriptors into the live structure collection at `0x0062ba8c` before
  `structure_candidate_rebuild_cargo_membership_and_scaled_rate_tables` `0x00411ee0` rebuilds the
  per-cargo runtime summary tables. The current local file-side result is now tighter too: the
  grounded recipe-book root at `0x0fe7` is preserved byte-for-byte across the checked map/save
  scenario pairs, so the loader can safely treat the twelve `0x4e1`-byte books as preserved
  scenario payload rather than a drifting save-only band. A conservative summary probe now only
  reports per-book head signatures, raw cap dwords at `+0x3ed`, and five raw line summaries rooted
  at `+0x3f1` so the file-side structure stays aligned with this grounded ownership. The
  player-facing line modes remain `Disabled`, `Demand Only`, `Supply Only`, and
  `Production Demand->Supply`, and the fourth mode is tighter now too: current wording around
  `1674`, `1675`, and `504` plus the downstream scaling path says it is the
  production-line mode governed by the shared annual production cap, where the entered annual amount
  stays on the supply side while the demanded side becomes the normalized input branch. The
  candidate-side accumulator pass reinforces that split by applying the shared production cap only
  to the supply-half runtime branch and bypassing that scaling on the normalized demand half. The
  lower gameplay side is tighter now too: `structure_candidate_query_cargo_runtime_summary_channels`
  `0x00412650` is the first grounded consumer beneath that rebuild chain, because it lazily rebuilds
  four per-cargo summary banks and returns one direct-supply channel, one cap-normalized supply
  channel, one demand or input channel, and one scaled production-output subrow channel for a
  requested cargo id. The internal indexing is tighter now too: the direct-supply lane indexes from
  `[desc+0x1c]`, the demand or input lane uses that same resolved cargo id in the no-subrow branch,
  and the scaled production-output lane indexes each subordinate row directly from
  `[desc+0x44+row*0x1c]`, with no post-resolution failure guard between the importer writes and the
  summary-bank updates. So the strongest current read is narrower than a full cargo-id decode: if
  the imported low-16 marker rows fail the exact matcher at `0x0041e9f0`, the resulting `0` ids
  will still hit the first summary-bank bucket inside `0x00412650`, but the semantic meaning of
  cargo id `0` itself remains ungrounded. The sibling helper
  `structure_candidate_supports_or_references_cargo_id`
  `0x004129d0` then uses those same banks plus the cached cargo-membership arrays to answer whether
  a live candidate materially references a cargo at all. One compare step tighter, the raw line
  lanes now split cleanly by scenario family while still preserving map->save identity inside each
  checked pair. `Alternate USA.gmp` and `Autosave.gms` match at the raw line-content level: books
  `0..4` keep mixed line areas, their `line02` slots carry the recurring nonzero mode words
  `0x00110000`, `0x000b0000`, `0x000b0000`, `0x00130000`, and `0x00180000`, and the same `line02`
  slots also carry one recurring supplied token `0x000040a0`; the neighboring `line00/line01`
  slots carry the same recurring demanded token lanes such as `0x00010000`, `0x72470000`,
  `0x6f430000`, `0x694c0000`, and `0x694d0000`. `Southern Pacific.gmp` and `p.gms` also match at
  the raw line-content level, but the same rooted line slots stay zero in the checked pair.
  `Spanish Mainline.gmp` and `g.gms` again match at the raw line-content level yet carry a distinct
  nonzero pattern: books `0..4` keep mixed line areas, line-level supplied tokens include
  `0x00170000`, `0x00150000`, `0x00004040`, and `0x00004000`, demanded tokens include
  `0x00010000`, `0x68430000`, and `0x6c410000`, and the later `line02` mode words stabilize at
  `0x00070000` then `0x00010000`. So the loader can now safely treat these raw line lanes as
  preserved scenario payload with family-specific signatures, even though the exact cargo-id and
  mode-enum semantics still need separate grounding. One inference is tighter now too: when those
  demanded-token words are zero in the low 16 bits and printable in the high 16 bits, the byte
  order reads as short two-letter stems such as `Gr`, `Co`, `Li`, `Mi`, `Ch`, and `Al`, which fit
  the current scenario cargo-name families `Grain`, `Corn`, `Livestock`, `Milk`, `Cheese`, and
  `Alcohol` from `RT3.lng`; the runtime probe now exposes those only as probable ASCII stems, not
  as fully grounded cargo-id decodes. The supplied-token side is now bounded as a separate layout
  family rather than forced into that same stem model: the `Alternate USA` family uses one stable
  low-16 marker `0x000040a0` only in `book00..04.line02`, the `Southern Pacific` family leaves the
  supplied lanes zero in the checked pair, and the `Spanish Mainline` family splits between two
  high-16 numeric tokens `0x00170000` and `0x00150000` in `book00/01.line01` plus the later low-16
  markers `0x00004040`, `0x00004000`, and `0x00004040` in `book02..04.line02`. The probe now
  exposes those conservatively as token-layout classes `high16-ascii-stem`, `high16-numeric`, and
  `low16-marker`, without claiming that the non-stem numeric or marker families are decoded yet.
  One more structural layer is stable enough to name conservatively: the checked nonzero recipe
  rows repeatedly fall into four line-signature classes. `Alternate USA` books `0..4` all expose
  one `demand-numeric-entry` at `line00` (`0x00010000`), one `demand-stem-entry` at `line01`
  (`Gr/Co/Li/Mi` stems), and one `supply-marker-entry` at `line02` (nonzero mode plus
  `0x000040a0`). `Spanish Mainline` books `2..4` expose that same three-line pattern with
  `Ch/Al` stems and the `0x00004040/0x00004000` marker family, while books `0/1` only expose the
  earlier `supply-numeric-entry` form at `line01`. So the loader can now distinguish recurring row
  roles such as demand-stem versus supply-marker without pretending the marker payloads themselves
  are decoded. The importer-side branch map is tighter now too because local `objdump` over
  `0x00435630` shows that only nonzero mode dwords materialize into `0xbc` runtime descriptors:
  mode `0` lines are skipped entirely, mode `1` enters the demand-only branch, mode `3` enters the
  dual demand-plus-supply branch, and every other nonzero mode falls into the supply-side branch.
  In the checked corpus that means the recurring `demand-numeric-entry` and `demand-stem-entry`
  rows in `Alternate USA` and `Spanish Mainline` are preserved scenario-side line records but do
  not become live runtime descriptors, while the later `supply-marker-entry` rows are the ones that
  actually reach the runtime import path. The runtime probe now exposes that directly as
  `imports_to_runtime_descriptor` plus one conservative `runtime_import_branch_kind`.
  The raw token windows beneath those branch labels are tighter now too. The checked mode-zero
  demand rows preserve string-bearing windows at `line+0x1c`, and the current probe shows those
  conservatively as prefixed ASCII previews such as `..Grain`, `..Corn`, `..Livestock`, and
  `..Milk`; local `objdump` over `0x0041e9f0` then shows the importer feeding the corresponding
  token buffer into an exact cargo-name matcher built over the live cargo collection at
  `0x0062ba8c`. By contrast, the imported `supply-marker-entry` rows feed nonprintable windows such
  as `.@...` from `line+0x08` through that same matcher, and the resolver path currently shows no
  special-case decoding for those marker forms. So the strongest static read is now: the stem-like
  demand rows preserve cargo-name text but are skipped because their mode is zero, while the
  nonzero imported marker rows are the live descriptor inputs yet likely fail exact cargo-name
  resolution unless another upstream transform exists.
  The wrapper layer above that query no longer looks like a hiding place for special treatment
  either. Local `objdump` now shows `0x00412960` simply summing the two supply-side floats returned
  by `0x00412650`, while `0x004129a0` returns the single scaled production-output lane directly;
  neither wrapper checks for cargo id `0` after the query returns. The broader world-side
  accumulator at `0x0041e7be` is tighter in the same way: it calls `0x00412650`, requires all four
  returned channels to be positive before continuing, and only then scales those four channel
  values by one linked-instance count from `0x00413940` into caller-owned accumulators. So the
  current strongest read remains structural rather than semantic: unresolved marker rows can still
  propagate through the first bank bucket, but the first place that meaning matters is a normal
  positivity-gated cargo-channel consumer, not a dedicated null-cargo branch.
  The caller side is narrower than before too. The steady-state site bitset owner
  `placed_structure_rebuild_candidate_cargo_service_bitsets` `0x0042c690` starts its inner cargo
  loop at id `1` and only walks upward through the current live cargo count, so it never
  intentionally queries cargo id `0`. The broader placed-structure sweep around `0x00452e60`
  tightens the same boundary from above: when the requested cargo id is nonzero it resolves the
  backing candidate and enters `structure_candidate_supports_or_references_cargo_id`, but when the
  requested id is exactly `0` it skips that cargo-reference helper entirely and falls through to a
  different linked-site or station-or-transit gate. Current local `objdump` now shows that bypass
  first requiring one subtype latch through the placed-structure vtable `+0x70`, then resolving the
  linked site id at `[site+0x2a8]` through the placed-structure collection `0x006cec20`, and then
  forwarding that linked peer into the narrower predicate at `0x0047fd50`. That narrower helper is
  tighter than before too: it resolves the linked peer's backing candidate through the peer site id
  at `[peer+0x04]`, reads candidate class byte `[candidate+0x8c]`, and returns true only for the
  first three class values `0/1/2` while rejecting `3/4` and anything above `4`. So current local
  callers treat cargo id `0` as a nonstandard request bound to one linked-site reachability or
  classification side path, not one ordinary cargo lane they routinely probe.
  The vtable-`+0x70` latch itself is bounded a bit better now too. It still lacks a direct field
  decode, but every local callsite we checked around `0x0040d230`, `0x0040dba0`, `0x0040dbf0`, and
  `0x0040f670` uses that slot only as the precondition for touching `[site+0x2a8]` and the
  neighboring linked-site helpers `0x0047dda0`, `0x0047fd50`, and `0x004138b0`. That makes the
  safest current read a linked-site-bearing or linked-site-capable latch, strongly aligned with the
  subtype-`1` construction lane that is the only grounded writer of `[site+0x2a8]`, rather than a
  broad cargo or route-style predicate.
  The neighboring maintenance pair tightens that linked-site read further. Local `objdump` now
  shows `0x0040dba0` and `0x0040dbf0` as complementary tiny helpers that each require the same
  vtable-`+0x70` latch, resolve optional linked peer id `[site+0x2a8]` through `0x006cec20`,
  forward that linked peer (or null) into `0x0047dda0`, and then mirror opposite values into local
  byte `[site+0x42]` (`0` for `0x0040dba0`, `1` for `0x0040dbf0`). The route-entry side beneath
  them is tighter too: `0x0047dda0` reads route-entry anchor id `[peer+0x08]`, resolves that anchor
  through `0x006cfca8`, and only dispatches one of two route-entry vtable calls when
  `0x0048a090(1)` reports that all three anchor-slot dwords `[entry+0x206]`, `[entry+0x20a]`, and
  `[entry+0x20e]` are still `-1`. So the strongest current read is no longer just "linked-site
  capable" in the abstract: this latch consistently fronts the local linked-peer class gate
  `0x0047fd50`, the paired `[site+0x42]` route-entry state toggles, and the later linked-peer
  collection sweep `0x004138b0`, which keeps the `cargo id 0` bypass path firmly on the
  linked-site route-anchor or classification side rather than on an ordinary cargo lane.
  One smaller ownership boundary is tighter too: byte `[site+0x42]` is not private scratch owned
  only by that pair. Local `objdump` shows tiny direct setters at `0x0040cbc0` and `0x0040cbd0`
  plus a raw getter at `0x0040cbf0`, so the `0x0040dba0/0x0040dbf0` pair is writing one shared
  placed-structure state byte rather than inventing a route-entry-only scratch lane. One caution
  is tighter now too: there are later mode-gated reads at other addresses that also touch a
  `+0x42` byte on their own object layouts, but current local evidence does not yet prove those are
  the same placed-structure owner family, so the safest current note keeps only the immediate
  `0x0040cbc0/0x0040cbd0/0x0040cbf0/0x0040dba0/0x0040dbf0` cluster grounded together.
  The vtable side sharpens that split too. A local `.rdata` scan shows `0x0040dba0` and
  `0x0040dbf0` each appearing exactly once, together with `0x0040cbf0`, in one method table rooted
  at `0x005c8c50`; the constructor chain is tighter now too, because `0x0040c950` installs that
  same table as one concrete placed-structure specialization above the common base table
  `0x005cb4c0`, while `0x0040c970` tears the same specialization back down to the base before the
  temporary object is freed. By contrast the raw set or get trio
  `0x0040cbc0/0x0040cbd0/0x0040cbf0` also appears in several sibling tables such as `0x005c9750`
  and `0x005dd1f0`. So the strongest current structural read is that byte `[site+0x42]` belongs
  to one broader placed-structure virtual interface, while the linked-peer route-entry toggles are
  one specialization-specific override pair inside that family rather than generic setters used by
  every sibling.
  One negative boundary is tighter now too: the
  raw token words in this recipe block do not look like the already grounded shell-side
  `AnyCargo/AnyFreight/AnyExpress` selector-table ids from `0x00621e04/0x00621e10`, so the current
  best read is that these on-disk line tokens are not just copied UI selector ordinals or the same
  small express-side id family in another wrapper. One broader collection pass also now ties
  the editor rule side back into runtime filtering:
  `structure_candidate_collection_refresh_cargo_economy_filter_flags` `0x0041eac0` rebuilds
  per-candidate flag `[candidate+0x56]` across the live structure collection, and current grounded
  callers show it rerunning directly off the runtime cargo-economy latch at `[0x006cec74+0x25f]`,
  which aligns this lane with the editor's `Disable Cargo Economy` special condition rather than
  leaving it as a purely editor-owned recipe page. The first common live gate beneath that filter is
  now bounded too: `structure_candidate_is_enabled_for_current_year` `0x0041e220` is the shared
  year-and-filter check used by the collection refresh and later candidate-selection branches, while
  `structure_candidate_rebuild_local_service_metrics` `0x0041e2b0` is a setup-side local service
  scorer that already consumes the same enabled candidate records through world-grid sampling. One
  steady-state world-side consumer is now grounded as well:
  `placed_structure_rebuild_candidate_cargo_service_bitsets` `0x0042c690` walks linked placed
  structures, filters live category-`2` candidates through
  `structure_candidate_is_enabled_for_current_year`, and compacts the direct and scaled supply-side
  channels from `0x00412960` and `0x004129a0` into per-cargo bitsets on the placed-structure record.
  The next site-side owner layer is tighter now too:
  `placed_structure_refresh_linked_candidate_flag4` `0x0042c8f0` refreshes the sibling state bit at
  `[site+0x0e6]`, `placed_structure_refresh_candidate_service_state` `0x0042cdf0` ties that flag
  refresh to the cargo-service bitset rebuild,
  `placed_structure_rebuild_candidate_local_service_tables` `0x0042ce00` then performs the heavier
  per-site candidate score rebuild over the aligned float and word tables at `[site+0x107]`,
  `[site+0x02]`, and `[site+0x6c]`, and `placed_structure_refresh_local_service_score_bundle`
  `0x0042d580` is now the local wrapper that chains that rebuild into the neighboring post-passes
  before the world-grid owner continues. Those post-passes are tighter too:
  `placed_structure_apply_route_linked_service_caps` `0x0042cc50` is the first route-backed cap pass
  over the rebuilt local tables,
  `placed_structure_redistribute_local_service_pressure_from_neighbors` `0x0042c1b0` is the
  neighboring-site redistribution pass, and `placed_structure_clamp_candidate_service_age_table`
  `0x0042cb30` is the final recent-service clamp over the primary per-candidate word table. Above
  that refresh lane, `placed_structure_query_candidate_local_service_metrics` `0x0047e240` is the
  first higher-level query, `placed_structure_count_candidates_with_local_service_metrics`
  `0x0047e330` counts how many candidates currently produce that query,
  `placed_structure_get_nth_candidate_id_with_local_service_metrics` `0x0047e620` is the ordinal
  selector over that same visible candidate family,
  `placed_structure_query_cached_express_service_class_score` `0x0047e390` caches one parallel class
  score for the express family now strongly aligned with `Passengers`, `Mail`, and `Troops`,
  `placed_structure_refresh_candidate_local_service_comparison_cache_against_peer_site`
  `0x0047eb90` rebuilds one peer-site comparison cache over the same local-service inputs, and
  `placed_structure_select_best_candidate_id_by_local_service_score` `0x0047f910` is the best-hit
  selector above the direct and directional local-service query pair. Those site-side scores now
  have grounded shell read-side consumers too:
  `shell_station_detail_format_freight_and_express_summary` `0x00506be0` formats the visible
  `Freight: %1` and `Express: %1` lines in `StationDetail.win`, and the same station-detail family
  now has a deeper candidate-service lane:
  `shell_station_detail_set_active_candidate_service_preview` `0x00504ae0` stores the active
  `(station id, candidate id)` pair for the world-side preview scan,
  `shell_station_detail_clear_active_candidate_service_preview` `0x00504a90` tears that pair back
  down, `shell_station_detail_update_candidate_service_entry` `0x00504ba0` is the shell-side entry
  updater above that preview pair, `shell_station_detail_format_candidate_local_service_summary`
  `0x00504bea` uses `placed_structure_query_candidate_local_service_metrics` together with localized
  ids `681`, `682`, and `2813` to build the visible candidate service text,
  `shell_station_detail_build_to_from_haul_summary_widget` `0x00505150` now grounds the paired `To`
  and `From` hauled-traffic strip widgets, `shell_station_detail_present_to_from_haul_stats_popup`
  `0x00504770` owns their click-through annual and lifetime `hauled TO/FROM this station` popup,
  `shell_station_detail_refresh_nearby_structure_jump_rows` `0x00505470` owns the five-row
  nearby-structure jump lane, and `shell_station_detail_refresh_candidate_service_rows` `0x00505760`
  is now the larger row-list owner that enumerates active candidate-service entries and wires
  `shell_station_detail_update_candidate_service_entry` into the per-row click path.
  `shell_station_list_format_freight_and_express_availability_summary` `0x00506e50` feeds the
  station-list summary `%1 has %2 freight loads and %3 express loads available for hauling...`, and
  the paired modifier helper `shell_station_list_handle_center_or_rename_action` `0x00506d50` owns
  the visible Shift-center and Ctrl-rename row actions. The report side is clearer as well:
  `0x004d3060` is the dedicated `Stats - Trees` constructor over `map_editor_tree_stats_report`,
  `0x004d3080` is the actual `General Validation` constructor over
  `map_editor_general_validation_report`, and the same page table also now grounds `Stats - Cargo`,
  `Stats - City/Region`, `Stats - City Count`, `Event Variable Values`, and the neighboring
  event-validation page. The remaining open editor edge is therefore mostly the deeper gameplay
  meaning of those site-side service scores and flag bits, not page ownership.

- Station-detail overlay: the shell-side candidate preview pair now has a grounded world consumer
  too. `world_render_station_candidate_service_map_overlay` at `0x0043f640` reads the active
  `(station id, candidate id)` pair from `0x005ee4fc` and `0x005ee500`, scans the placed-structure
  collection, and then splits the legend by candidate mode. When the active candidate carries a
  nonzero route-style byte at `[candidate+0x46]`, the overlay uses the heavier helper
  `placed_structure_query_candidate_directional_route_overlay_summary` at `0x0047e690` in both
  directions between the preview station and each scanned site and formats the resulting directional
  rows as `3874` `Coming To %1` and `3875` `Going From %1`. When that byte is zero, the same overlay
  falls back to the direct local-service path through
  `placed_structure_query_candidate_local_service_metrics` and formats the two legend rows instead
  as `3876` `Current Supply @ < %1` and `3877` `Current Demand @ > %1`. Empty directional lanes
  collapse to `3878` `--None--`, and one title lane falls back to literal `All`. Current disassembly
  no longer supports treating `3872` `Already Connected by Another Company` or `3873` `Not
  Connected` as direct overlay-body emits.
- Station-detail overlay, corrected boundary: the neighboring connection-state note pair now appears
  to live in a city connection-bonus label formatter, not in `0x0043f640`. That formatter is now
  bounded as `city_site_format_connection_bonus_status_label` at `0x004207d0`: it directly chooses
  localized ids `3868` through `3873` after consulting the reusable city-peer scan
  `city_connection_bonus_exists_matching_peer_site` at `0x00420030`. Separately, `3879` `Out of
  Sync` is grounded under the multiplayer preview dataset path instead:
  `multiplayer_preview_dataset_service_launch_state_and_warn_out_of_sync` at `0x0046b780` checks
  global `0x006cd91c`, raises the `Out of Sync` shell status through `0x5386e0`, and then continues
  through the wider multiplayer preview launch-state service. So the station-detail overlay
  currently owns only the `Coming To`, `Going From`, `Current Supply`, `Current Demand`, `--None--`,
  and `All` legend lanes.
- Station-detail overlay, ownership side: one reusable site helper is grounded now too.
  `placed_structure_query_linked_company_id` at `0x0047efe0` resolves the current placed structure's
  linked instance through `0x0062b26c` and returns its company id from `[instance+0x276]`; the
  adjacent city bonus formatter at `0x004207d0` compares that id against the active company selector
  before choosing whether a scanned site should carry `3871` `Connected By Another Company` or
  `3872` `Already Connected by Another Company`. The larger caller boundary is no longer open
  either: the first bounded announcement owner above this formatter family is now
  `company_evaluate_and_publish_city_connection_bonus_news` at `0x00406050`, which re-enters the
  peer-route candidate builder at `0x004046a0` and later publishes one of the localized
  city-connection bonus news strings `2888`, `2890`, or `2921` through the shell news path.
- Station-detail overlay, peer-selector side: the city bonus formatter no longer depends only on
  boolean peer existence. The companion helper
  `city_connection_bonus_select_first_matching_peer_site` at `0x00420280` is now grounded as the
  first-match selector paired with `city_connection_bonus_exists_matching_peer_site`: it walks the
  same city-peer candidate set, applies the same site-class table plus the narrower
  station-or-transit and linked-instance class-byte flags, and returns one representative matching
  peer site id instead of a boolean. `city_site_format_connection_bonus_status_label` reuses that
  selector after the note checks so it can recover one linked company context from the selected
  peer. The remaining open edge here is therefore above this formatter family, not inside the
  peer-scan pair itself.
- Station-detail overlay, caller side: the reusable bridge between the status formatter and the
  company news lane is now bounded too. `city_connection_bonus_build_peer_route_candidate` at
  `0x004046a0` reuses `city_connection_bonus_select_first_matching_peer_site` with both selector
  flags forced on, samples the selected peer's derived coordinates through `0x0047df30` and
  `0x0047df50`, and then either tries the shared heavy builder
  `city_connection_try_build_route_with_optional_direct_site_placement` `0x00402cb0` or falls
  back to the smaller wrapper `city_connection_bonus_try_compact_route_builder_from_region_entry`
  `0x00404640` before handing the result back to the company-side announcement sweep at
  `0x00406050`. The score side of that announcement lane is tighter now as well:
  `city_compute_connection_bonus_candidate_weight` at `0x004010f0` provides the per-city opportunity
  weight, `company_query_min_linked_site_distance_to_xy` at `0x00405920` provides the nearest
  linked-site distance term, `company_count_linked_transit_sites` at `0x00426590` provides one of
  the company-side caps, `company_compute_connection_bonus_value_ladder` at `0x00425320` supplies
  the bounded company-side value scalar, and
  `company_compute_prime_rate_from_issue39_scenario_baseline` at `0x00424580` now bounds the
  shared prime-rate-side helper that this lane reuses beside the raw issue-`0x39` total,
  `scenario_state_sum_issue_opinion_terms_raw` at `0x00436710` now bounds the raw additive
  issue-total helper beneath that term, and `company_connection_bonus_lane_is_unlocked` at
  `0x00427590` is the small boolean gate above the ladder. Wider governance and CompanyDetail xrefs
  now tighten slot `0x2b` into the rolling net-profits lane reused by annual finance checks and a
  per-share/history formatter, while the report-history descriptor table now aligns raw slot `0x09`
  with the Income Statement fuel-cost lane surfaced by tooltip `1309`. The wider result now reads
  more like recent net profits minus recent fuel burden than a governance-pressure term. That now
  also sharpens the annual finance lane at `0x00401c50`: the first bankruptcy branch reads as
  sustained cash-and-debt stress over recent profits and fuel burden, the later fallback branch as
  a deeper `-300000` cash / three bad years cleanup trigger, and the later stock-issue branch reads
  as a price-to-book-versus-coupon approval ladder rather than a generic support vote. The tail is
  cleaner now too: it compares total retired versus newly issued principal to choose the `2882..2886`
  debt headline family, then publishes `2887` separately from the accumulated repurchased-share
  count. The sibling news owner above the same
  city-pair route family is bounded now too:
  `simulation_try_select_and_publish_company_start_or_city_connection_news` `0x00404ce0`
  filters and scores candidate city entries, re-enters the same shared heavy builder through
  `city_connection_try_build_route_between_region_entry_pair` `0x00404c60` for the dense pair
  sweep and the final retry, and then publishes `2889` `%1 has started a new company - the %2`
  or `2890` `%1 has connected %2 to %3.` through the shell news path. The remaining open edge on
  this branch is therefore narrower now: it is mostly whether `0x39` should be read as the
  narrower city-connection public-opinion lane or as part of a broader management-attitude family,
  not the ownership of the connection-bonus formatter, peer-route candidate path, or company news
  gate.
- Station-detail overlay, route-list side: the neighboring helper
  `placed_structure_append_unique_route_entry` at `0x0047f010` is now grounded as the
  append-if-missing builder for the six-byte route-entry list rooted at `[site+0x462]` and
  `[site+0x466]`. That matters here because the directional overlay query at `0x0047e690` consumes
  the same list, so the remaining uncertainty is no longer list ownership. It is down to the exact
  semantics of each entry's `u32` payload.

## Next Mapping Passes

- Resolve the owner-side callback roles behind the validated GameSpy packet branches, especially
  `[route+0x9c]`, `[route+0xa0]`, `[route+0xa4]`, and `[route+0xd4]`.
- Determine whether any later world-mode branch beneath the frame owner bypasses the shell
  controller input path for non-cursor gameplay input, since the current grounded overlay and cursor
  helpers still reuse `0x006d4018`.
- Keep detailed pending-template or transport work scoped to the specific atlas edges that remain
  unresolved.