feat(runtime): recompute loaded Control owner profiles

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`. Для проверки другого отображения второй прогон оставляет тот же