Решили: признак «под этим экраном нужен задник» переехал с вызывающего на сам экран —
UiScreen.RequiresBackdrop, собирает навигатор, и этот запрос сильнее гейта живого боя.
Почему: экран настроек по рефу Guildrun остался без панели, и то, что под ним, стало частью
раскладки. Но признак жил в ScreenKind, который назначает call-site: из главного меню настройки
открывались как Page (стол за ними был), из паузы забега — как Modal (за ними шёл живой мир).
Билдер один, вид два, и по коду экрана понять, что у него за спиной, было нельзя.
Отвергли два варианта. Первый — сделать настройки Page в обоих случаях: тип отвечает за глушение
ввода и за скрытие нижних экранов, и ради фона пришлось бы менять поведение, заодно погасив подсветку
таба режима. Второй — глубокий скрим на весь кадр (успел прожить полчаса): он лечил симптом, причина
которого — недоехавший задник, и рядом с настоящим столом читался бы чёрным экраном, ровно как
заливки, снесённые по QA #50.
Сказано: «Подожди. А зачем затемнение? У рефа полноценный экран-задний фон с красивым эффектом. Можем просто на фоне сделать необычную текстуру, шейдер или градиент (или их сочетание?)» (05.08.2026, сессия 35d14bea). Затемнение было моей заплаткой; вопрос Макса развернул заход к доставке фона.
Грабли: живой бой за меню гасит стол отдельным гейтом в MenuBackdropView — для меню это верно
(бой ради того и заведён), для настроек нет, поэтому у ScreenBackdropChangedEvent появилось второе
поле OverBattle, а ребро публикации считается по паре, а не по одному флагу. И OpenOverMenu с
опциональным вторым параметром перестала преобразовываться в Action<Func<VisualElement>> — метод с
опциональным аргументом в такой делегат не конвертируется, на call-site нужна лямбда.
Владелец правды: UiScreen.cs, UiNavigator.HasVisibleBackdropRequest,
UiRootBootstrap.RefreshShell, тесты UiNavigatorTests.BackdropRequest_*.