Задача PERF-SWEEP: поиск узких мест по всей игре, а не в одной сцене

Постановка пользователя: ручной проход уровня с логом фаз + комната/тайл,
дальше оптимизация конкретной комнаты.  Записано вместе с блокером —
брейкпоинтами это делать нельзя (эмуляция падает в проценты от реального
времени, играть невозможно); варианты: тап на порт бордюра в Lua-мосте
(не привязан к адресам кода) или самозамер программой в растрах (работает
и на железе).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

applications/PoP/roomtest/TASKS_OPEN.md

@@ -874,6 +874,59 @@ tp/10 у факелов таблицей, пустой слот соперник
 
 ## P1 — берётся в любой момент
 
+### <a id="perf-sweep"></a>PERF-SWEEP. Поиск узких мест по ВСЕЙ игре, а не в одной сцене
+
+**Постановка (пользователь, 2026-08-18):** «пока мы тестируем на регресс
+только одну сцену; надо придумать механизм проверки узких мест по всей
+программе — ручной проход уровня, в логи пишутся такты каждой фазы с
+информацией, в какой комнате это происходит (возможно, в каком тайле Кид),
+ищем максимумы по уровню и оптимизируем уже конкретную комнату».
+
+Сцена 13/23 закрывает ПИК, но она одна: механики, которых в ней нет
+(чомперы, бой, мышь, зеркало, толпа стражей), в бюджет никто не проверял.
+
+#### Чем НЕЛЬЗЯ это делать — и почему
+
+Тем, чем меряем сейчас.  Брейкпоинты с `printf ...; g` на четырёх границах
+фаз роняют эмуляцию в проценты от реального времени — **ручной проход так не
+сыграть**, а именно ручной проход и есть суть задачи.  Плюс две мелочи,
+которые уже стоили времени: адреса зондов надо переснимать после КАЖДОЙ
+пересборки (`.lst` + база модуля), а кольцо `clog` переполняется — сегодня
+первый прогон принёс один «покой», каскад успел вытесниться за 75 с
+ожидания.
+
+#### Куда смотреть
+
+**Вариант А — тап на порт бордюра в Lua-мосте (рекомендую).**  `PROF(n)`
+это `out (0xFE), a`, то есть границы фаз УЖЕ размечены в железе.
+`install_write_tap` на порт даёт колбэк без остановки CPU — накладные
+несравнимо меньше брейкпоинта, играть можно.  Главный бонус: **тап не
+привязан к адресам кода**, переснимать после пересборки нечего.  «Где» берём
+оттуда же: Lua читает `cur_room` и `Kid.curr_col/curr_row` по адресам из
+`roomtest.map` (их выдавать в маленький файл при сборке, чтобы не парсить
+map руками).  Пишем CSV: кадр, комната, тайл Кида, синяя/зелёная/циан/работа,
+период.
+
+**Вариант Б — программа меряет себя сама, в РАСТРАХ.**  Тактов Z80 изнутри
+не видно, но нам они и не нужны: бюджет сформулирован в растровых кадрах, а
+позицию луча видно поллингом бита 5 порта 0xFE (то же, чем живёт
+`gfx_wait_vsync`).  Разрешение ~1/256 кадра ≈ 1 700 тактов — для поиска
+узких мест с запасом.  Дороже варианта А по месту в резиденте, но
+единственный, который работает **на живом железе**, а не только в MAME —
+а такт MAME это 2,4× номинала Z80 (memory `sprinter_wait_states_2x`), и
+рано или поздно сверяться придётся с железом.
+
+#### Что считать результатом
+
+Не «дамп кадров», а сводка: максимум каждой фазы **по комнатам**, число
+кадров сверх 400 000 и сверх растрового кадра 430 000, и топ комнат по
+худшему кадру.  Дальше — точечная оптимизация той комнаты, как делали с
+13/23.
+
+Смежное: сцена и метод — [`../docs/perf_l13_room23.md`](../docs/perf_l13_room23.md);
+фазы — [зелёная](../docs/perf_green_phase.md), [циан](../docs/perf_cyan_phase.md).
+
+
 ### <a id="t-render"></a>T-RENDER. Тесты слоя отрисовки: «в запечку не попадает транзиент»
 
 **Откуда взялось** (пользователь, 2026-08-18, по итогам