Зацеп за кромку нижнего ряда: do_fall пускает ряд до 3 + check_grab в midair

Уровень 7, комната 14: спуск с ряда 0 на ряд 2 через зацеп (повис на кромке
кнопки (0,2), отпустил, взялся за (2,2)) не работал ни при какой фазе и
задержке — Кид пролетал мимо и разгонялся до fall_y = 33, после чего окно
зацепа закрыто уже по скорости.

Корень: do_fall не давал curr_row выйти за 2, а check_grab целится в тайл
ряда curr_row-1 — то есть ряд 2 своей комнаты становится целью только при
curr_row == 3.  В оригинале (seg005:0030) inc_curr_row безусловный, а
get_tile для ряда 3 уходит по links.down (find_room_of_tile, seg006:005D).

- pop_map.c do_fall: inc_curr_row теперь 2 -> 3; ветка «достиг y_land»
  гейтится по curr_row <= 2 (при ряде 3 ни in_wall, ни land звать нельзя —
  тайлов своей комнаты там нет, а до y_land[4] дело не доходит: комнату
  меняет check_leave_below на y >= 211).
- pop_map.c check_action: восстановлена ветка ACT_MIDAIR (кадры 102..105,
  seg006:0619) — первые четыре кадра падения, где fall_y ещё не разогнан,
  зацеп не работал вовсе.  Отсюда же «иногда цепляется, иногда нет».
- tests-host/t_grab.c: регресс grab_below_room_edge_window_exists — сцена
  комнаты 14 + переход в 15 по pop_fell_out.  До фикса ни одного зацепа,
  после — окно из 8 фаз X при задержках 0..5 кадров; проверяется и
  играбельность (зацеп при «отпустил и сразу зажал Shift»).
- roomtest.c + pop_guard.h: чит-навигация ставит Кида на верхний ряд в
  комнате 14 уровня 7 (GRAB_DOWN_LEVEL/ROOM) — снизу этот спуск не проверить.
  Общее правило (снизу вверх) не тронуто: в верхнем ряду пола чаще нет и Кид
  проваливается сразу после телепорта.

Проверено: tests-host 5/5 (55 в [grab]), size-check OK, живьём в MAME —
Кид повис на кромке (2,2): frame=91 y=55 row=0 room=15.

Доски: GRAB-BELOW-ROOM в BUGS_CLOSED, GRAB-KBD-TIMING в BUGS_OPEN (отложен
пользователем до готовности всех уровней), план L7-FEATHER в TASKS_OPEN.

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

applications/PoP/roomtest/BUGS_OPEN.md

@@ -22,6 +22,41 @@
 | [T-1](#t-1) | пики перерисовываются безусловно | оптимизация | открыт |
 | [BUG-SPIKE-1](#bug-spike-1) | пики залипают выдвинутыми рядом с Кидом | **низкий** | маловоспроизводим: ни сценарием, ни попиксельной подгонкой X не поднимается |
 | [BUG-CHOMP-JUMP-1](#bug-chomp-jump-1) | прыжок с места вплотную к чомперу: кадр с отступом назад | **низкий** | маловоспроизводим: на повторе не поднялся; на пререлиз |
+| [GRAB-KBD-TIMING](#grab-kbd-timing) | зацеп в падении срабатывает менее стабильно, чем в оригинале | **после всех уровней** | открыт: подозрение на клавиатурный модуль, не на физику |
+
+---
+
+<a id="grab-kbd-timing"></a>
+## GRAB-KBD-TIMING. Зацеп в падении срабатывает НЕ ТАК СТАБИЛЬНО, как в оригинале — РАЗБОР ПОСЛЕ ВСЕХ УРОВНЕЙ
+
+> **Решение пользователя (2026-08-12): отложено до готовности всех уровней.**
+> Механика работает, это вопрос ощущения, а не проходимости.
+
+**Наблюдение (пользователь).**  Вход на уровень 7: Кид влетает в комнату сверху
+и, пролетая мимо края пола, МОЖЕТ за него зацепиться — но получается заметно
+реже, чем в оригинале.  «Похоже, это проблемы нашего клавиатурного модуля».
+
+**Что уже сделано и почему это НЕ закрывает вопрос.**  В ходе разбора
+[GRAB-BELOW-ROOM](BUGS_CLOSED.md#grab-below-room) восстановлена ветка
+`ACT_MIDAIR` в `check_action` (кадры 102..105 — начало падения, где `fall_y` ещё
+не разогнан): раньше на этих четырёх кадрах `check_grab` не звался вовсе, то
+есть окно зацепа было короче оригинального.  Это должно было добавить
+стабильности, но саму гипотезу про клавиатуру не проверяет.
+
+**Куда смотреть, когда дойдут руки.**  Порядок именно такой — сначала
+измерить, потом чинить:
+
+1. Снять, ЧТО видит движок в момент падения: `pop_ctrl_shift_held()` покадрово
+   (Shift зажат заранее — читается ли он каждый кадр, или FIFO SIO отдаёт
+   состояние с пропусками; см. memory `kbd_raw_fifo_drain`,
+   `kbd_overrun_wipe_modifiers` — оба прошлых бага были именно про модификаторы).
+2. Сверить с оригиналом ширину окна по кадрам: у нас `check_grab` доступен на
+   102..105 (midair) + весь `ACT_FREEFALL`, как в seg006 — расхождений в коде
+   быть не должно, значит расхождение либо во вводе, либо в темпе игры
+   ([L1-SPEED](TASKS_OPEN.md#l1-speed): игра идёт на ~39 % быстрее оригинала,
+   а окно зацепа отмеряется В КАДРАХ — то есть по времени оно у нас короче).
+3. Хост-тест `t_grab.c` уже умеет мерить ширину окна (карта исходов по фазе X и
+   задержке нажатия) — на нём и проверять «стало стабильнее».
 
 ---