feat(runtime): recompute loaded Control owner profiles

docs/appendices/knowledge-boundaries.md

@@ -569,23 +569,52 @@ resource-device значения во время игры.
 и mirror-варианты передают свой transform-вектор setter-у; это отдельная
 граница, как и более поздние placement/tick.
 
-Полный Rust loader теперь вызывает FAC0 при построении
-`build_control_device_projection` и публикует результат в
-`MissionControlOwnerProfile::load_projection`. Игнорируемый corpus-тест
-`full_load_builds_effective_control_device_table_for_mine_unit_dat` на лицензированном
-`min_l_n1.dat` проверяет 11 устройств, все 25 соответствий provider ordinal
-модели и упорядоченные значения `row +0x20`. Его агрегаты —
-`0x470833fc/0x4897e712/0x4d9452cb` для `+0x530/+0x534/+0x538`; исходный и
-начальный mutable word `26` равны `0x7f7fffff`. Это подтверждает Rust full-load
-результат на оригинальных ресурсах, но не совпадение с полным нативным load
-оригинала. Поведение позже при placement/tick и физический смысл raw-полей
-остаётся неизвестным. Точные RVA, owner layout и векторы приведены в
-[описании изолированного прохода FAC0](script-vm.md#изолированный-проход-fac0).
+Полный Rust loader теперь выполняет FAC0, затем FCA0 при построении
+`build_control_device_projection_with_class`. `MissionControlOwnerProfile::load_projection`
+сохраняет отдельный результат FAC0, а `fca0_projection` — статус следующего
+прохода. FCA0 проверяет класс **владельца** `owner +0x50`: класс `9` сразу
+возвращает неизменённую копию; это не условие по device factory tag `9`. Любой
+известный класс, отличный от `9`, включая `0`, проходит общий расчёт. В Rust
+`MissingNativeControlClass` означает, что проекция не восстановила метаданные
+класса, а не то, что оригинальная DLL не содержит класс. `Fac0Unavailable`
+применяется только к не-классу-9 ветви, потому что класс `9` выходит до проверки
+FAC0.
 
-Остаётся сравнить этот полный mine load с original loader при тех же входных
-данных и продолжить трассировку `LoadControlSystem`, `LoadPhysicalModel`,
-`CreateCollManager` и collision objects, если потребуется связать profile words
-с shapes, contacts или реакцией на движение.
+FCA0 суммирует selector `0xe00` в обратном порядке по устройствам с текущим
+descriptor tag `5`. Изолированный x86-вектор исполняет оригинальный reader
+`0x21d00` и FCA0. Статическая проверка двух factory vtables подтверждает общий
+reader `0x21d00` и setter `0x21d50` для tags `5`/`26`; provider getter `0x0dc40`
+использует `owner +4`, а canonical `QueryInterface(0x204)` задаёт
+`owner +0x38 -> owner +0x0c`.
+В каноническом constructor/event-4 пути scalar `+0x1a8` и means `+0x354/+0x358`
+равны `1.0`. На исходном Control.dll с SHA-256
+`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e` FCA0
+подтверждена по RVA `0x0fca0` при x87 control word `0x007f`. Слова
+`[0,1,2,6,7,8,9,10,11]` в canonical-default векторе имеют биты
+`40200000 c0a00000 40c00000 3f800000 40000000 41200000 41e70000 c22d4000 40e70000`.
+
+Лицензированный тест `full_load_builds_effective_control_device_table_for_mine_unit_dat`
+настоящего `min_l_n1.dat` теперь проверяет class `3`, `fca0_projection = Ok(())`,
+11 устройств и все 25 provider rows. Его девять target words
+`[0,1,2,6,7,8,9,10,11]` равны
+`40000000 40000000 40000000 00000000 00000000 00000000 00000000 00000000 00000000`;
+word `26` после FAC0 остаётся `0x7f7fffff`, а оригинальный блок, FAC0 агрегаты
+`0x470833fc/0x4897e712/0x4d9452cb` и 25 значений строк сохраняются. Это Rust
+full-load результат на оригинальных ресурсах, а не сравнение полного native
+Unit DAT loader-а или gameplay. Rust helper поддерживает только конечные входы
+и промежуточные значения домена `normal-or-zero`; прочие битовые случаи остаются
+вне заявленного диапазона.
+
+Полный динамический жизненный цикл после начальной загрузки не подтверждён:
+поздние изменения owner scalar/means, activation, игровые часы, Control tick и
+placement не сведены в одну проверенную трассу и не включены в Rust-проекцию.
+Отдельные constructor, setter и loader-пути уже прослежены; физические единицы
+слов профиля и накопителей остаются неизвестны. Для закрытия границы нужны
+динамическая трассировка и сравнение полного Unit DAT load с оригинальным
+loader-ом при одинаковых ресурсах и условиях.
+Подробные RVA, QI/provider layout, арифметика и пределы векторов приведены в
+[описании изолированного прохода FAC0](script-vm.md#изолированный-проход-fac0)
+и [разборе FCA0](script-vm.md#изолированный-проход-fca0).
 
 ## DirectPlay wire
 

docs/appendices/script-vm.md

@@ -1105,15 +1105,143 @@ scales `[1, 1, 1]`. Это подтверждено только для обыч
 rebind; отдельные AddNewObject/mirror scale setters и более поздние placement/
 tick пути в этот вывод не входят.
 
-Теперь полный Rust loader вызывает FAC0 в `build_control_device_projection`
-после сборки provider rows и устройств. Игнорируемый тест
-`full_load_builds_effective_control_device_table_for_mine_unit_dat` прогнан на
-лицензированном `min_l_n1.dat`: он проверяет 11 устройств, сопоставление всех
-25 provider rows и весь упорядоченный вектор `row +0x20`. Агрегаты mine равны
-`+0x530 = 0x470833fc`, `+0x534 = 0x4897e712`, `+0x538 = 0x4d9452cb`; исходное и
-начальное mutable word `26` оба равны `0x7f7fffff`. Это измеренный результат
-Rust loader-а на оригинальных ресурсах, но не сравнение полного load результата
-с оригинальным loader-ом. Имена и физические единицы полей остаются неизвестны.
+Теперь полный Rust loader вызывает FAC0 и затем FCA0 в
+`build_control_device_projection_with_class`, после сборки provider rows и устройств.
+`MissionControlOwnerProfile::load_projection` и `fca0_projection` хранят
+отдельные статусы этих проходов. Игнорируемый тест
+`full_load_builds_effective_control_device_table_for_mine_unit_dat` на
+лицензированном `min_l_n1.dat` проверяет 11 устройств, 25 provider rows, весь
+упорядоченный вектор `row +0x20`, три FAC0 агрегата и результат FCA0. Агрегаты
+mine равны `+0x530 = 0x470833fc`, `+0x534 = 0x4897e712`,
+`+0x538 = 0x4d9452cb`; исходное и начальное mutable word `26` оба равны
+`0x7f7fffff`. Девять слов FCA0 по индексам `[0,1,2,6,7,8,9,10,11]` равны
+`[40000000,40000000,40000000,00000000,00000000,00000000,00000000,00000000,00000000]`.
+Это измеренный результат Rust loader-а на оригинальных ресурсах, но не
+сравнение полного load результата с оригинальным loader-ом. Имена и физические
+единицы полей остаются неизвестны.
+
+#### Изолированный проход FCA0
+
+`Control.dll` SHA-256
+`bcb86318089028548a178b03a21accdce15df0cc85ddd91674cf3c2f55012c6e`
+вызывает `FUN_1000fca0` (RVA `0x0fca0`) после `FUN_1000f940` и `FUN_1000fac0`
+в каноническом обработчике event `4/null`. Входной класс Control читается из
+`owner +0x50`. Первая проверка FCA0 (`0xfca6`) немедленно возвращается при
+классе `9`; после этой проверки для такого класса нет чтений или записей
+профиля, таблицы либо модели. Это класс владельца, а не factory tag отдельного
+устройства. Все известные классы, отличные от `9`, включая `0`, входят в общий
+путь; отсутствие класса в Rust проекции выдаёт `MissingNativeControlClass` и не
+означает, что его нет в оригинальном объекте. `Fac0Unavailable` относится
+только к этому общему, не-классу-9 пути: класс `9` завершает FCA0 до проверки
+FAC0.
+
+На каноническом Unit DAT пути host получает `QueryInterface(0x204)` и передаёт
+результат в `owner +0x38`. Проверенная цепочка через Agent и CBuilding приводит
+к интерфейсу `owner +0x0c`; его vtable `0x3d1b4` имеет count slot `+0x0c ->
+0x8830`, query slot `+0x18 -> 0x2bb40` и getter текущего descriptor tag
+`+0x20 -> 0x2c390`. Этот интерфейс уже привязан до FAC0/FCA0.
+
+Функция `0x2bb40` выбирает E00 reader `0x100` для текущего tag `5` и reader
+`0x300` для текущего tag `26`. У factory `5` vtable `0x3cdf8`, у factory `26`
+vtable `0x3ce38`; обе таблицы указывают на общий `FUN_10021d00` в slot `+0x10`
+и `FUN_10021d50` в slot `+0x1c`. Factory `26` в dispatch `0x2d4b0` также
+использует конструктор `0x20800`, как и factory `5`. Поэтому все четыре пары
+current tag/factory tag `(5,5)`, `(5,26)`, `(26,5)` и `(26,26)` используют
+доказанные методы. E00 для текущего tag `5` считает
+`coefficient[0] * provider.current_type1`; он не использует `M` по `+0x4c` и
+descriptor word `8`. Текущий tag `26` тем же общим reader-ом дополнительно
+умножает на `M`. Это правило не меняет отдельные callbacks бюджета или запись
+factory-26 selector `0x500`.
+
+FCA0 передаёт в owner query порядковый номер `i`; query `0x2bb40` находит
+устройство `i` и вызывает его reader. Уже reader `FUN_10021d00` получает provider
+key из поля устройства `+0x04`. Provider getter `FUN_1000dc40` (RVA `0x0dc40`)
+получает `this = owner +4`, читает таблицу по `owner +0x55c`, а ключ выбирает
+строку `table + key*0x2c`; текущее type-1 значение находится по `+0x14` строки.
+Индекс устройства и ключ provider row — разные значения с разными задачами.
+
+Конструктор owner `FUN_10006bf0` (RVA `0x6bf0`) задаёт scalar `+0x1a8 = 1.0`
+и вызывает `FUN_10014260`, который записывает `1.0` в `+0x354/+0x358`.
+Проверенные ветви канонического event `4/null` и FAC0 не меняют эти три поля
+до FCA0. Это подтверждённые defaults начального прохода; значения после
+activation, update или иных host writes здесь не проверялись.
+
+Для любого не-класса-9 пути начинается нулевая сумма. Устройства посещаются в
+обратном порядке; только текущий descriptor tag `5` отправляется в selector
+`0xe00`. При успешном native query его `f32`-результат прибавляется к сумме и
+сразу сохраняется обратно в `f32` stack slot:
+
+```text
+sum = 0.0f
+for i = device_count - 1 down to 0:
+    if current_tag(i) == 5 and query(i, 0xe00) succeeds:
+        sum = f32(sum + e00(i))
+```
+
+Затем из `+0x354/+0x358` вычисляется mean и `weight = mean * sum`. Отношение
+`r = current[26] / original[26]` задаёт два сохранённых в `f32` коэффициента:
+`factorA = (r + 1) * 0.5` и `factorB = r * 0.75 + 0.25`. Упрощённая запись ниже
+сохраняет порядок зависимостей, но не показывает границы x87 spill:
+
+```text
+for i in 6..9:
+    value = owner[0x1a8] * original[i]
+    value = value * weight
+    value = value * factorA
+    cap = original[i]
+    if cap < abs(value):
+        value = -cap if value < 0 else cap
+    current[i] = value
+
+for i in 9..12:
+    value = original[i] * weight
+    value = value * factorB
+    current[i] = value + value
+
+for i in 0..3:
+    current[i] = original[i] + original[i]
+```
+
+В первом триплете scalar умножается на слова `6..8`, затем результат умножается
+на `weight` и `factorA`; промежуточные значения слов `6` и `7` сохраняются в
+f32 slots между операциями, а слово `8` дольше остаётся в x87. Во втором
+триплете сначала умножаются исходное слово и `weight`, затем `factorB`, затем
+значение удваивается; первые два промежуточных произведения сохраняются, третье
+остаётся в x87. После этих триплетов слова `0..2` удваиваются из исходного блока.
+Точные spill-границы видны в RVA `0xfca0..0xfef9`. Native-векторы исполнялись
+при x87 control word `0x007f`.
+
+Ограничитель срабатывает, когда исходный cap с сохранённым знаком меньше
+`abs(value)`. Тогда ветвь проверяет `value < 0`: при отрицательном значении
+результат равен `-cap`, иначе — `cap`; в `else` входят и `+0`, и `-0`.
+Поскольку cap сохраняет знак оригинального слова, отрицательная граница может
+развернуть знак результата.
+
+Построенный helper считает из копии, уже подготовленной FAC0; исходный массив
+профиля остаётся отдельным. Его результат публикуется только при полном успехе,
+поэтому ошибка FCA0 не оставляет частично записанных слов. В публичной модели
+`load_projection` остаётся результатом FAC0, а `fca0_projection` хранит только
+статус FCA0. Rust ограничивает эту арифметику конечными normal-or-zero входами
+и промежуточными значениями: NaN, бесконечности, subnormal и промежуточные
+результаты вне поддерживаемого диапазона f32 отклоняются. Это граница модели
+Rust, а не доказательство того, что оригинал не принимает такие биты.
+
+Оригинальная FCA0 и методы DLL дали следующий canonical-default x86-вектор на
+синтетической backing-памяти: класс `3`, E00 `[6, -0.75]`, scalar и оба mean
+равны `1`, `current[26]/original[26] = 6/4`. Слова
+`[0,1,2,6,7,8,9,10,11]` после прохода равны:
+
+```text
+40200000 c0a00000 40c00000 3f800000 40000000 41200000 41e70000 c22d4000 40e70000
+```
+
+Этот вектор подтверждает функцию на оригинальной DLL и выбранных getter-ах, но
+не выполняет полный native Unit DAT loader или игровой цикл. Licensed mine-тест
+отдельно проверяет Rust full-load: class `3`, `fca0_projection = Ok(())`, все
+11 устройств и 25 provider rows; слова `[0,1,2,6,7,8,9,10,11]` равны
+`40000000 40000000 40000000 00000000 00000000 00000000 00000000 00000000 00000000`.
+FAC0 агрегаты и строки сохраняются. Поздние динамические scalar/mean, activation,
+Control tick, placement и сравнение полного native load остаются открытыми.
 
 #### Входной класс Control при загрузке Unit DAT
 

docs/tomes/06-behavior.md

@@ -717,33 +717,89 @@ Rust full-loader теста на оригинальных ресурсах. Ве
 `None`, без дочернего fallback или синтетических нулей. Точные native writes и
 открытые вопросы о смысле полей приведены в [техническом разборе загрузки CTLD](../appendices/script-vm.md#профиль-владельца-control-при-загрузке-ctld).
 
-Изолированный x86-вектор подтвердил общий проход `Control.dll!FUN_1000fca0`
-(RVA `0x0fac0`): расчёт начинает с исходного profile word 26, а затем пишет
-производное значение в изменяемую копию и заполняет три поля-накопителя
-владельца, а также `+0x20` каждой строки provider. Для этого выбираются два
-сырых слова `Slot68` через `Node38` state 0 / LOD 0, учитываются cache tag 27 и
-устройства таблицы.
-Смысл слов `Slot68` и итоговых чисел не установлен; мы не называем их массой
-или площадью.
+Изолированный x86-вектор подтвердил общий проход `Control.dll!FUN_1000fac0`
+(RVA `0x0fac0`): этот шаг FAC0 начинает с исходного profile word 26, затем
+заполняет три накопителя владельца и поле `+0x20` provider rows. Для него
+выбираются два сырых слова `Slot68` через `Node38` state 0 / LOD 0, учитываются
+cache tag 27 и устройства таблицы. Смысл `Slot68` и итоговых чисел не
+установлен; мы не называем их массой или площадью.
 
-Rust повторяет эту формулу изолированным helper-ом, и его тест совпадает с
-оригинальным кодом на синтетических векторах при x87 control word `0x007f`.
-В обычной цепочке загрузки AniMesh начинает с масштабов `[1, 1, 1]`, а вызванные
-до FAC0 обработчики привязки модели, FX и collision-компонентов эти поля не
-меняют. Поэтому загрузчик использует подтверждённые значения конструктора, а
-не scale из TMA. Теперь `build_control_device_projection` выполняет FAC0 после
-сборки provider rows и списка устройств и публикует результат вместе с копией
-профиля владельца.
+Для обычной начальной загрузки AniMesh создаёт scale `[1, 1, 1]`. Проверенные
+обработчики модели, FX и столкновений до FAC0 его не меняют. Поэтому первый
+проход получает значения конструктора, а не scale, записанный в TMA. Отдельные
+маршруты создания и последующее размещение объекта остаются другими путями.
+
+### Начальная FCA0-проекция профиля
+
+После FAC0 оригинальная Control выполняет второй проход FCA0 и обновляет только
+выбранные слова отдельной изменяемой копии. Условие раннего выхода проверяет
+**класс владельца Control**: класс `9` сразу пропускает FCA0. Это не тег
+фабрики отдельного устройства `9`: в
+лицензированном mine-профиле есть устройство с factory tag `9`, но класс
+владельца равен `3`, поэтому FCA0 выполняется. Любой известный класс, отличный
+от `9`, включая `0`, идёт по общему пути. Если Rust не смог вывести класс из
+ресурсной цепочки, он возвращает отдельный статус; это означает отсутствие
+проекции в Rust, а не отсутствие класса в оригинальной DLL.
+
+На начальном пути конструктор задаёт scalar и два средних значения как `1.0`.
+Устройства читаются с конца списка;
+в сумму попадают только записи с текущим descriptor tag `5`. Их `0xe00`
+значение использует ключ устройства и `current_type1` соответствующей строки
+provider. Читатели фабрик `5` и `26` общие; для текущего tag `5` формула
+`coefficient[0] * provider.current_type1` не использует ни multiplier `M`, ни
+descriptor word `8`. Ветки current tag `26` дополнительно умножают на `M`, но
+не участвуют в сумме FCA0, которая фильтрует текущий tag `5`.
+
+Упрощённая карта зависимостей показывает, почему важен порядок обхода и какие
+слова меняются; строки формул сами по себе не задают порядок native-вычислений:
+
+```text
+sum = 0
+for index in reverse(0..device_count):
+    if current_tag(index) == 5:
+        sum = f32(sum + query_e00(index))
+
+mean = (mean_a + mean_b) * 0.5
+weight = mean * sum
+r = current[26] / original[26]
+A = (r + 1) * 0.5
+B = r * 0.75 + 0.25
+current[0..3] = 2 * original[0..3]
+current[6..9] = native_signed_cap(original[6..9] * scalar * weight * A)
+current[9..12] = 2 * (original[9..12] * weight * B)
+```
+
+Порядок x87 операций и spill границы приведены в техническом описании. Нативный
+ограничитель срабатывает, когда исходный cap с сохранённым знаком меньше
+`abs(value)`. Тогда проверяется `value < 0`: отрицательное значение даёт `-cap`,
+иначе возвращается `cap`; ветвь `else` включает `+0` и `-0`. Поэтому
+отрицательный cap способен изменить знак выхода.
+Здесь в query передаётся порядковый номер устройства; его getter уже сам
+использует ключ устройства для выбора строки provider. Точный порядок чтений,
+промежуточных записей и проверки приведён в
+[техническом разборе FCA0](../appendices/script-vm.md#изолированный-проход-fca0).
+
+Rust хранит исходные слова отдельно, считает кандидата из копии после FAC0 и
+публикует слова FCA0 только после полного успеха. Статус `load_projection`
+остаётся результатом FAC0, а `fca0_projection` отдельно сообщает исход
+следующего прохода; ошибка FCA0 сохраняет уже подготовленную FAC0-копию.
+Обычный путь подтверждён при x87 control word `0x007f` для конечных normal-or-zero
+входов и промежуточных значений. Реализация не утверждает поддержку
+денормализованных, NaN, бесконечных или выходящих за диапазон промежуточных
+значений.
+
+Оригинальная FCA0 и выбранные getters совпали на изолированном x86-векторе;
+точные raw bits, module hash, вызовы и ABI приведены в технической главе.
 
 Игнорируемый corpus-тест полного загрузчика на оригинальном
-`UNITS/BUILDS/MINE/min_l_n1.dat` подтверждает сопоставление всех 25 provider
-rows с начальными узлами и проекцию 11 устройств. Для профиля mine получены
-агрегаты `+0x530 = 0x470833fc`, `+0x534 = 0x4897e712` и
-`+0x538 = 0x4d9452cb`; тест сверяет также все 25 значений строк. Это результат
-Rust loader-а на лицензированных данных, а не сравнение с полным native load
-оригинала. Смысл слов `Slot68` и итоговых чисел по-прежнему неизвестен. Точные
-входы, вектор и границы приведены в
-[техническом разборе загрузки CTLD](../appendices/script-vm.md#изолированный-проход-fac0).
+`UNITS/BUILDS/MINE/min_l_n1.dat` теперь проверяет class `3`, успешный статус FCA0,
+все 11 устройств, 25 provider rows, FAC0 snapshots и девять выходных слов.
+Для mine-профиля первый триплет FCA0 даёт `[2, 2, 2]`, два следующих — нули;
+не все целевые слова обязаны отличаться от исходных. Тест также сохраняет все
+11 устройств, 25 provider rows и результаты FAC0. Это проверка Rust loader-а
+на оригинальных лицензированных ресурсах, а не сравнение полного native Unit
+DAT load или gameplay. Поздние изменения means/scalar, activation, tick и
+placement остаются отдельными открытыми вопросами.
 
 Для tag `19` фабрика создаёт объект с его исходными классом и vtable. Базовый
 конструктор `FUN_100218b0` задаёт multiplier `+0x4c = 1.0`. Override через
@@ -940,10 +996,13 @@ Preview не загружает профили.
 `FUN_100198e0` (RVA `0x198e0`) суммирует их успешные `0xe00` запросы. FParkan
 делает то же для загруженной таблицы в её исходном порядке и затем умножает
 сумму на профильный `Transfer_Ore_OffBoard`. Записи tag `5`, `10` и `21` в общей
-таблице в этот список не попадают. Запрос `0xe00` проходит по ключу устройства
-в исходную provider-таблицу и пока поддержан только для текущего descriptor
-tag `26` с factory tag `26`; для него результат равен
-`provider * fixed_words[11] * multiplier`. Лицензированный тест загружает
+таблице в этот список не попадают. Это фильтр самого `0x1002`, а не ограничение
+доступности общего Control-запроса `0xe00`: он поддержан для текущих descriptor
+tags `5` и `26` с factory tags `5` и `26`. Owner query получает порядковый
+номер устройства; getter использует ключ этого устройства, чтобы выбрать строку
+provider. Для current tag `5` значение равно `coefficient[0] * provider`, без
+множителя `M` и descriptor word `8`; для current tag `26` результат равен
+`provider * coefficient[0] * M`. Лицензированный тест загружает
 оригинальные CTL/NDP и полную миссию с этим Unit DAT. В установленном
 `min_l_n1.dat` class word равен `0x80000004`, поэтому исходный прогон выбирает
 `prof_mine.var`. Для проверки другого отображения второй прогон оставляет тот же