feat(runtime): project initial Control mesh metadata

docs/tomes/06-behavior.md

@@ -859,6 +859,29 @@ tag-26 ряда получается `1.0` provider × `1.0` coefficient × `1.0
 `1.0`. Эти запросы используют начальные provider-значения после конструкторов,
 а не результаты живого игрового тика.
 
+У Control есть и начальные сведения о модели узла, но их таблица не совпадает
+с NDP. Sidecar задаёт состав и порядок provider-строк, а поле type-1 `+0x14`
+получает начальное значение `1.0` от нативного конструктора. AniMesh отдельно
+собирает глобальный список MSH-узлов. При создании строки Control берёт
+mesh-состояние по её порядковому номеру в общей таблице provider, а не пытается
+угадать пару по локальному номеру строки sidecar-а. Например, после 22
+корневых строк номер 22 указывает на первый глобальный узел присоединённой
+`EXTO`-модели, который
+происходит из её локального узла `1`.
+
+В снимке это необязательное поле: `None` означает, что для данного номера не
+удалось получить MSH-узел; исходные запросы к NDP от этого не исчезают. Поэтому
+начальное значение и поза модели остаются отдельными частями состояния:
+
+```rust
+initial_mesh_state: Option<MissionControlNodeInitialMeshState>
+```
+
+Внутри снимка хранятся родительский индекс, переведённые флаги Control и число
+начальных стадий. Узлы корневой модели добавляются все, а присоединённая `EXTO`
+начинает с локального узла `1`. Это описывает исходную настройку: код пока не
+переключает стадии в ходе игры и не исполняет полный Control tick.
+
 После загрузки количество в строках может меняться. Контроллер распределяет
 добавку либо пропорционально свободному месту, либо по очереди: при максимумах
 `[30, 60, 50]`, текущих значениях `[10, 20, 0]` и добавке `22` первый способ