Решили: шов «мероприятие заказывает бой» привязывается в КОНСТРУКТОРЕ BattleHost, сам он
регистрируется обычным singleton’ом, а рождает его ActivityHost.Open вместе с мероприятием.
Почему: точки входа VContainer (IStartable.Start) диспатчатся на СЛЕДУЮЩЕМ кадре, а узел
заказывает первый бой в том же кадре, в котором открылось мероприятие. RequestLaunch отвечал
«некому запустить бой», узел уходил в Aborted, петля акта возвращала игрока в главное меню — то
есть «Начать забег» выглядело как кнопка «выйти в меню». Отвергнуто: (1) ждать кадр в петле акта —
лечит симптом и заводит гонку с другим временем; (2) проверять CanLaunch и повторять заказ —
второй владелец момента запуска; (3) оставить точкой входа и звать Start руками — привязка
осталась бы зависимой от того, кто вспомнит её позвать.
Сказано: «И да, когда нажимаю начать забег - меня тупо кидает в главное меню. Критичный баг, надо исправить в первую очередь» (2026-08-22, QA-заметки Макса, заход 12:00).
Грабли: по логу это читалось как поломка карты или сейва — падало на конкретном узле c2r3,
четыре прогона подряд, и выглядело привязанным к содержимому забега. Настоящая улика нашлась
замером в живой игре: сразу после ActivityHost.Open приватное поле BattleSession._launch пусто,
а кадром позже — занято. Резолв самого BattleHost при этом проходит синхронно: контейнер объект
отдаёт, но конструктор до первого резолва не вызывается вовсе, и «объект есть» ещё не значит «шов
стоит».
Владелец правды: Assets/_Project/Scripts/Game/Flow/BattleHost.cs,
Assets/_Project/Scripts/Game/Activity/ActivityHost.cs, тест BattleSeamBindingTests.