fix(runtime): warm behavior before mission Init

docs/appendices/knowledge-boundaries.md

@@ -79,8 +79,7 @@ control word процесса.
 `[(500.2857, 751.8217), (728.0, 449.0)]` и записи `[(500, 752, 0),
 (728, 449, 1)]`; preview кампании сохраняет package и статус `Unsupported`,
 не применяя частичные записи. Это подтверждает загрузчик и узкий Init resolver
-Rust, но не доказывает, что штатный host вызывает `Init` при старте оригинальной
-миссии.
+Rust.
 
 Нативный конструктор показывает предупреждение при координате выше `10000`, но
 продолжает работу. Rust моделирует числовую запись, а не это UI-предупреждение;
@@ -92,9 +91,44 @@ Rust, но не доказывает, что штатный host вызывае
 Rust исполнителя, не правило оригинального dispatcher-а. Ошибочные ссылки и
 типы остаются ошибками в обоих режимах.
 
-Открыты вызов `Init` при штатном старте Iron3D и проверка другой миссии с
-непустым `Init`. Не восстановлены host-ingress `Init` в игровом цикле и общий
-dispatcher остальных событий.
+Для GOG-сборки также найден статический host call path в `Init`. В
+`iron3d.dll!FUN_1005ff40` (RVA `0x5ff40`) одна ветвь сначала проходит записи
+кланов и вызывает для них `FUN_100392e0`, затем вызывает `FUN_10039440` (RVA
+`0x39440`). Эта функция передаёт AI callback-у пару явных аргументов через
+vtable slot `+0x14`. В `ai.dll!FUN_10001ae0` (RVA `0x1ae0`) аргумент callback-а
+записывается в `AI+0x3fc`; затем объект `AI+0x438` получает вызов Behavior
+vslot `+0x2c`. В проверенной `Behavior.dll` (SHA-256
+`ddfbdbde07832358fe6e35e01c8dba9b58e7313789498b6049ed51d4ed9baf99`)
+`FUN_1001adb0` (RVA `0x1adb0`) выполняет начальную подготовку расписания.
+Метод ищет первый `Init` только при нулевом latch
+`AI+0x8a8`, а при dispatch временно ставит и снимает recursion guard
+`AI+0x78`. В этой ветви поэтому известны callback ingress и порядок
+warm-start → `Init`, но смысл аргумента callback-а здесь не сопоставлен с Rust
+`MissionMode`.
+
+Изолированный x86 oracle вызывает исходные `iron3d.dll!FUN_10039440`,
+`ai.dll!FUN_10001ae0` и script dispatcher на синтетических записях и проверяет
+режим, guard, latch, Handler(19) writes и повторный вызов. Отдельный oracle
+исполняет `Behavior.dll!FUN_1001adb0` с искусственно заданной очередью, сверяя
+срок, шаг LCG и очистку полей. Это подтверждает ABI и локальные переходы исходных
+функций, но не доказывает, что полная штатная загрузка выбранной миссии в
+оригинальном процессе доходит до этой ветви в том же порядке. Метод
+`FUN_10001ae0` оставляет latch `+0x8a8` сброшенным, когда `Init` не найдено;
+если оно найдено при уже занятом guard `+0x78`, dispatch пропускается, но latch
+всё равно устанавливается. Rust пока запускает обработанный поднабор при каждой
+полной загрузке и не моделирует аргумент callback-а `AI+0x3fc`, guard `+0x78` или
+latch `+0x8a8`.
+
+Rust `load_mission` принимает явный `queue_time_ms`, а не читает оригинальное
+время очереди. Новый `Engine` начинает локальный Behavior RNG с seed `1` и
+учитывает шаги генератора этой стартовой последовательности; не восстановлены
+другие потребители исходного генератора, поэтому равенство полной случайной
+последовательности не утверждается. Начальная фаза выполняется после регистрации
+объектов в создаваемом мире Rust;
+это интеграционный выбор runtime, а не подтверждённая эквивалентность всех
+host construction phases. Не проверена другая лицензированная миссия с
+непустым `Init`, не восстановлены игровой tick Behavior и общий dispatcher
+остальных событий.
 
 Для `Handler(30)` отдельно подтверждены обратный вызов `iron3d.dll` RVA
 `0x611d0` (SHA-256 `d1dc4ea8535e2069b0a05c9e8be2724dd438ba44cca7a83007d8b2e50f9e35fa`),