Зелье медленного падения (перо) + цвет пузырьков по типу зелья

L7-FEATHER: тип 3 (уровень 7, комната 1) больше не пустой TODO.

- pop_map.c: pop_feather — счётчик кадров эффекта (POP_FEATHER_FRAMES = 225,
  ванильный порог do_timers seg003:0517; привязку к звуку взять неоткуда).
  fall_accel — ускорение 1 / потолок 4 (seg006:057C) вместо 3 / 33.
  proc_get_object case 3: взвести эффект + зелёная вспышка на 3 кадра.
- pop_kid.c: опкод JMP_IF_FEATHER (0xF7) больше не пропускает адрес
  безусловно — под пером прыгает по нему, то есть seqtbl уводит падение и
  удар в ветки stepfloat/bumpfloat (плавные кадры, без урона).
- roomtest.c: pop_flash_red -> pop_flash_color (жёлтый/красный/ЗЕЛЁНЫЙ);
  сброс pop_feather в pop_start_level (seg003:189).
- Цвет пузырька по ТИПУ зелья (seg008:652), чего у нас не было вовсе:
  3/4 зелёный, 5/6 СИНИЙ, остальные красный.  Mono-блиттера с параметром
  цвета в libbgi нет, поэтому цвет запекается при упаковке: pop_pack_bg.py
  кладёт те же 7 кадров ещё дважды (id 30..36 зелёные, 40..46 синие),
  pop_potion_draw выбирает набор.  Атлас 23 -> 37 спрайтов (+423 Б).
- Синее зелье «−HP» приведено к оригиналу (seg006:1892): своей вспышки не
  ставит (красный кадр даёт общий flash_if_hurt — иначе экран красился
  дважды), а на уровне зелий забирает ПОЛОВИНУ запаса HP.

Такое зелье стоит уже на пройденном уровне 2 (комната 13, тайл (1,3)),
а также ур.8 комн.2 и весь ур.15 — до сих пор оно было красным.

Тесты: phys_feather_fall_is_slow_and_harmless (обычное падение с двух рядов
разгоняется и стоит HP, под пером скорость <= 4 и HP целое); tests-host
5/5 (1727 в [phys]), size-check OK.

Расхождения с ванилью — в docs/impl_diff.md (перо ловит только Кида;
синее зелье без своей вспышки).

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

applications/PoP/roomtest/BUGS_OPEN.md

@@ -58,6 +58,37 @@
 3. Хост-тест `t_grab.c` уже умеет мерить ширину окна (карта исходов по фазе X и
    задержке нажатия) — на нём и проверять «стало стабильнее».
 
+### Протокол замера (написан 2026-08-12, чтобы следующий заход начался с фактов)
+
+Пользователь связывает с этим же и «двойные срабатывания не вовремя».  Прежде
+чем трогать драйвер — доказать, что он вообще виноват: **сегодняшний случай
+«Кид ходит как с зажатым Shift» оказался артефактом MCP-моста, а не драйвера**
+(`pause` освободил 6 незакрытых входов, которые плагин переустанавливал каждый
+кадр; как только они отпустились, драйвер снял бит сам).  То есть break-коды
+драйвер обрабатывает верно, и ложная тревога здесь стоила часа.
+
+Что мерить:
+
+1. **Поток скан-кодов**: кольцевой лог в трамплине прерывания
+   (`libc/irq/_irq_tramp.c` / `kbd_raw_poll.c`) — байт кода, флаг make/break,
+   номер кадра.  Читать из MAME по адресу буфера (`mem`), как читаем `_Kid`.
+2. **Что увидел движок**: `pop_ctrl_shift_held()` и битмап `_kbdraw_down`
+   (адрес — из `.map`, для roomtest 0xAEF9) на тех же кадрах.  Расхождение
+   «код пришёл, а движок не увидел» = потеря в драйвере; «кода не было, а бит
+   стоит» = потеря break (то, что подозревает пользователь).
+3. **Сцены**: бег с отпусканием, разворот, вис + отпускание Shift, падение с
+   зажатым заранее Shift (вход на уровень 7), быстрое повторное нажатие
+   (проверка «двойного срабатывания» — typematic, см. memory
+   `kbd_overrun_wipe_modifiers`).
+
+Что считать нормой: каждому make ровно один break; между make и видимым
+`kbd_raw_down()` — не больше кадра; при удержании typematic-повторы НЕ должны
+доходить до `pop_ctrl` как новые нажатия (диспетчер ждёт фронт).
+
+Отдельная гипотеза, которую замер тоже закроет: окно зацепа отмеряется В
+КАДРАХ, а игра идёт на ~39 % быстрее оригинала ([L1-SPEED](TASKS_OPEN.md#l1-speed))
+— тогда «менее стабильно» это не клавиатура, а темп, и чинить надо темп.
+
 ---
 
 <a id="уровень-2"></a>