feat(runtime): load Control node providers for resource queries

docs/appendices/knowledge-boundaries.md

@@ -307,18 +307,48 @@ mappings; preview и объекты без Unit DAT root её не строят.
 `bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`) tag-26
 getter selector `0x300` восстановлен локально: RVA `0x21d00` читает provider по
 ключу `fixed_words[1]`, затем умножает provider, CTLD coefficient `fixed_words[11]`
-и поле объекта `+0x4c` именно в таком порядке. Rust helper принимает текущие
-provider и multiplier извне; он не восстанавливает их жизненный цикл или весь
-Control tick. В x86 oracle при x87 control word `0x007f` проверены порядок,
-signed zero, отрицательные входы, расширенный промежуточный диапазон и
-subnormal return. Helper ограничивает себя normal-or-zero значениями, поэтому
-явно отклоняет промежуточные случаи, где результат выходит за поддерживаемый
-диапазон f32, даже если позднее умножение вернуло бы его в диапазон. Это
-ограничение поддержки Rust helper-а, а не неверный native-результат.
+и поле объекта `+0x4c` именно в таком порядке. Provider getter RVA `0xdc40`
+читает type-1 поле `+0x14` строки, которую `FUN_10008b10` (RVA `0x8b10`)
+добавляет из NDP в таблицу с шагом `0x2c`; `FUN_1000b240` (RVA `0xb240`)
+инициализирует это поле как `1.0`. Начальный Rust snapshot повторяет порядок
+NDP строк корневого ресурса и примонтированных `EXTO` (без первой строки
+последнего), сохраняя исходные таблицу и строку как provenance. Ключ устройства
+сначала меняется по подтверждённому MSH mapping для `EXTO`, затем это готовое
+значение применяется напрямую как индекс provider sequence. Длина этой
+sequence определяется NDP: она не дополняется по числу узлов модели и ключ не
+пересчитывается ещё раз по числу provider rows. `INTO` provider строк не
+добавляет. Для примонтированного `EXTO` с пустым NDP невозможно безопасно
+применить native skip-first путь, поэтому Rust явно сообщает unavailable;
+таблица из одной строки допустима и даёт нулевой вклад. Если обязательный NDP
+sidecar недоступен, запрос `0xe00` сообщает это отдельно, оставляя независимые
+агрегатные selectors `1/2` доступными.
+
+Rust query обращается к загруженному объекту и поддерживает `0xe00` только для
+текущего descriptor tag `26` с factory tag `26`; другие активные typed tags и
+factory paths остаются явными границами. Snapshot показывает состояние сразу
+после native-конструкторов, но он не обновляется при Control tick-е. Native
+`FUN_10010f30` (RVA `0x10f30`) изменяет и ограничивает provider amount, а
+связанные callbacks переносят его между строками; их общий переход в Rust ещё
+не реализован. Поэтому вызов нельзя считать живым ресурсным симулятором.
+Behavior selector `0x1002` остаётся отдельной задачей: его множитель
+`Transfer_Ore_OffBoard` приходит из блока `+0x820`, но источник фактических
+текущих настроек для полного runtime-пути пока не подтверждён.
+
+В x86 oracle при x87 control word `0x007f` проверены порядок, signed zero,
+отрицательные входы, расширенный промежуточный диапазон и subnormal return.
+Rust запрос ограничивает себя normal-or-zero значениями, поэтому явно отклоняет
+промежуточные случаи, где результат выходит за поддерживаемый диапазон f32,
+даже если позднее умножение вернуло бы его в диапазон. Это ограничение
+поддержки Rust snapshot, а не неверный native-результат.
 
 В Unit DAT fixture `UNITS/BUILDS/MINE/min_l_n1.dat` проверена реальная связка
-`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в таблице из `22` строк,
-коэффициент `1.0`. Это не запись живого resource-device значения в миссии.
+`fr_l_mine.ctl` + `fr_l_mine.ndp`: tag `26`, ключ `2` в локальной NDP таблице
+из `22` строк, коэффициент `1.0`. Игнорируемый runtime-тест выполняет полный
+загрузочный путь, подтверждает root/`EXTO` размеры `22` и `4` и итоговые `25`
+provider rows после пропуска первого `EXTO` row. Он вызывает Rust query по
+восстановленному native правилу адресации и получает начальное значение `1.0`;
+getter оригинальной DLL здесь не исполняется. Это не запись живого
+resource-device значения во время игры.
 
 Закрывающий эксперимент: трассировать `LoadControlSystem`,
 `LoadPhysicalModel`, `CreateCollManager` и создание collision objects; связать

docs/tomes/06-behavior.md

@@ -732,8 +732,21 @@ Provider interface направляет selector `1` и ключ в Control RVA
 читается текущее type-1 значение выбранной строки. Затем selector умножает
 сначала provider на коэффициент, после чего на множитель: `provider * base *
 multiplier`. Коэффициент приходит из CTLD; NDP связывает ключ с описанной
-строкой, а текущее значение provider нельзя заменить предположением о состоянии
-мира.
+строкой. Native loader создаёт для этой строки отдельное runtime-состояние: у
+`Control.dll` (та же сборка, SHA-256
+`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`)
+`FUN_1000b240` (RVA `0xb240`) строит 11 слов строки provider и ставит её
+selector-1 поле `+0x14` в `1.0`. `FUN_10008b10` (RVA `0x8b10`) выбирает строки
+NDP, а `FUN_1000a100` (RVA `0xa100`) добавляет их в общую таблицу с шагом
+`0x2c`; getter `FUN_1000dc40` (RVA `0xdc40`) использует ключ устройства как
+индекс этой таблицы. Для корня загружаются все строки. `INTO` не добавляет
+строк, а примонтированный `EXTO` пропускает свою первую строку. Пустая
+таблица такого `EXTO` не содержит строки, которую native loader должен
+пропустить, поэтому Rust оставляет provider lookup недоступным; sidecar с одной
+строкой даёт пустой вклад. Если mount узел не разрешился, строки этого `EXTO`
+в таблицу не попадают. Это отдельная
+последовательность provider-строк: её длина берётся из NDP, она не дополняется
+до числа узлов MSH и не участвует во второй перенумерации ключа.
 
 Так этот селектор включён в цепочку добычи руды оригинала. В той же сборке
 `Behavior.dll` (SHA-256
@@ -747,24 +760,40 @@ multiplier`. Коэффициент приходит из CTLD; NDP связыв
 5.0 — RVA `0x22d90`; config selector 2 загружает блок через RVA `0x0a1a0`).
 Отдельный query `0x1005` (RVA `0xa490`) возвращает поле `+0x60`
 `Transfer_Power_Out` (имя — RVA `0x22e20`, default 100.0 — RVA `0x22d90`;
-setter — RVA `0xaa40`). Rust helper пока описывает один Control selector `0x300`
-при явно переданных входах; он не реализует эту сумму, Behavior-умножение или
-подключение к игровому циклу.
+setter — RVA `0xaa40`). В полной загрузке FParkan начальные provider-строки
+хранятся вместе с таблицей Control конкретного `ObjectHandle`. Запрос
+`0xe00` проходит по ключу устройства в этот снимок и пока поддержан только для
+текущего descriptor tag `26` с factory tag `26`; для него результат равен
+`provider * fixed_words[11] * multiplier`. Лицензированный тест загружает
+оригинальные CTL/NDP и подтверждает, что tag-26 запись с ключом `2` читает
+начальное значение строки `1.0`. Это проверка начального состояния после
+конструкторов, не результат живого игрового тика.
+
+Поведение provider-строк меняется и после загрузки: например,
+`Control.dll!FUN_10010f30` (RVA `0x10f30`) обновляет и ограничивает текущее
+значение, а соседние процедуры распространяют его между связанными строками.
+Эти изменения пока не отражены в Rust-снимке. Поэтому `0xe00` не является
+исполнением всего Control tick-а, а Behavior query `0x1002` не подключён к
+этому API; его множитель `Transfer_Ore_OffBoard` требует отдельного источника
+текущей конфигурации.
 
 На x87 control word `0x007f` каждое умножение округляет мантиссу до 24 бит,
 но промежуточная степень может выйти за диапазон `f32` и вернуться в него при
-следующем умножении. Rust helper поэтому принимает явные текущие значения
-provider и multiplier, проверяет tag, ключ и строку NDP, сохраняет порядок
-операций, но поддерживает только конечные нормализованные значения или ноль на
-входе, промежуточном и конечном этапах. Остальные случаи за этим численным
-диапазоном он отклоняет; полный x87 accumulator здесь не эмулируется.
+следующем умножении. Native oracle проверяет такой порядок для getter-а
+`0x300`. Rust запрос сохраняет тот же порядок, но поддерживает только конечные
+нормализованные значения или ноль на входе, промежуточном и конечном этапах.
+Остальные случаи за этим численным диапазоном он отклоняет; полный x87
+accumulator здесь не эмулируется.
 
 Лицензированный тест на Unit DAT `UNITS/BUILDS/MINE/min_l_n1.dat` проходит через
-компонент `fr_l_mine.ctl` и sidecar `fr_l_mine.ndp`: у найденного tag-26
-дескриптора ключ равен `2` из `22` строк, а raw коэффициент — `0x3f800000`.
-Тест передаёт helper-у искусственные текущие значения `1.0` только для проверки
-записи и привязки ключа; этот Unit DAT не является наблюдением живого Control
-tick-а.
+`fr_l_mine.ctl` и `fr_l_mine.ndp`: у найденного tag-26 descriptor ключ равен
+`2` в своей записи, raw коэффициент — `0x3f800000`. Корневой NDP содержит 22
+строки, sidecar примонтированного `EXTO` — 4; в общую provider-таблицу входит
+25 строк после пропуска локальной строки `0`. Тест также сравнивает порядок
+всех source-row индексов с порядком строк самих sidecar таблиц. Он вызывает
+Rust query по восстановленному native правилу адресации, а не getter оригинальной
+DLL на полной миссии. Значение `1.0` подтверждает начальное состояние по native
+конструктору, но не наблюдение живого Control tick-а.
 
 ### Control system и physical model