Разбор порядка отрисовки падающей плиты: найден корень, выбран вариант B

СИМПТОМ (пользователь, ур.11 к.14).  Кусок, отвалившийся от плиты нижнего
ряда, рисуется ПОВЕРХ соседней трясущейся плиты; при этом передний торец
соседа лежит поверх куска — порядок противоречив в разных частях
перекрытия.

КОРЕНЬ.  draw_mob (seg007:13E5) считает ряд объекта как
y_to_row_mod4(y) = (y+60)/63 % 4 - 1.  Из-за % 4 ряд 3 (кусок ушёл ниже
комнаты) и ряд −1 (кусок у потолка) дают ОДНО значение −1.  Оригинал
прогоняет его через get_tilepos -> get_tilepos_nominus и получает тайл 30,
а объекты с тайлом 30 рисуются в redraw_needed_tiles ПЕРВЫМИ, до всего
обхода тайлов.  Мы же передаём сырой −1 в мид-оверлей как «тайл объекта», и
гейт `row > pop_bg_obj_row` читает его как «объект в последнем ряду обхода»,
то есть «объект поверх всего», и отбрасывает возврат соседа.  Один и тот же
−1 у нас значит «сверху», у оригинала — «снизу».

Торец при этом виден потому, что приходит из ДРУГОГО слоя: draw_loose кладёт
loose_fram_bottom в backtable и foretable, минуя ptr_add_table, — тело плиты
обязан вернуть мид-оверлей, а его и выключает гейт.

ЧТО ПРОВЕРЕНО ЗАМЕРОМ (журнал решений в pop_dbg_ovl/pop_dbg_pass, зонды
ВРЕМЕННЫЕ и будут сняты):
 - на застывшем кадре: слот draw_y=194, r=−1, rt=2, оверлей позван, внутри
   отбрасывается гейтом;
 - пропуск оверлея на последнем кадре полёта ЗАКОНЕН: габарит куска уже
   ниже габарита тайла, перекрывать нечего;
 - в 13/23 кусок перекрывают 2-4 тайла (накопленно за полёт), включая СВОЮ
   клетку, — то есть «сосед справа» покрытие не исчерпывает;
 - перерисовок тайлов за кадр в 13/23: максимум 6, в покое 0.

ТУПИКИ, чтобы не ходить второй раз.  Клип объекта тут ни при чём:
add_mob_to_objtable ставит clip.right = 40, но клип применяется только при
chtab_flip_clip[chtab_id], а для chtab_6_environment там 0 — поле
игнорируется и в оригинале.  Пункт MOB-CLIP-RIGHT закрывается как
несуществующий.  Добавлять торец плиты в мид-оверлей тоже не надо: в
foretable он уже кладётся из fore_tile.

ВЫБРАН ВАРИАНТ B: классифицировать ряд объекта (вне 0..2 = корзина 30),
отдавать оверлею ориентир «раньше любого тайла» и расширить набор
перекрываемых тайлов на СВОЮ клетку.  Переносить проход отрисовки не нужно —
heal при этом не участвует, работа та же (оверлей = два блита в окне клипа),
разница с узким вариантом A всего один-два оверлея на кусок.

Заодно записана ОБЯЗАТЕЛЬНАЯ задача HEAL-WIDTH: ширины точечных heal'ов
взяты по клеткам (64), а фактический след плиты — 58/57 (замерено по
атласам: верх 32, правая грань 26 в подземелье и 25 во дворце).

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

applications/PoP/roomtest/TASKS_OPEN.md

@@ -258,6 +258,52 @@ MEM-BANK2, MEM-BANK5, CLIP-1, KBD-1, DBG-CHEATS.
 
 ## P0 — делаем сейчас
 
+### <a id="heal-width"></a>HEAL-WIDTH. Ширина точечных heal'ов не совпадает со следом перерисовки — ОБЯЗАТЕЛЬНО
+
+**Постановка (пользователь, 2026-08-18).**  Ширины heal'ов взяты «на глаз по
+клеткам», а не по реальному следу.  Сжатие до фактического следа даёт около
+**10 % площади** самой дорогой операции акселератора; по оценке пользователя
+5-6 % реального выигрыша.  Задача обязательная.
+
+**Измерено** (каталоги атласов, спрайты плиты):
+
+| часть плиты | подземелье | дворец |
+|---|---|---|
+| верх (`41/69/70`) | 32 × 13-14 | 32 × 13-14 |
+| правая грань (`42/71/72`) | **26** × 15-16 | **25** × 15-16 |
+
+То есть анимированный след ОДНОЙ плиты — `32 + 26 = 58` пикселей в
+подземелье и `57` во дворце.
+
+**Что стоит сейчас.**  В коде уживаются ДВЕ разные договорённости:
+
+- **60** = «свой тайл + свес соседа» — `pop_floor_bake` (там это записано
+  комментарием);
+- **64** = «две клетки» — `pop_loose_shake_draw`, `pop_spike_redraw`
+  («ширина 64 = обе ячейки»).
+
+Для трясущейся плиты 64 избыточны: хватает 58 (подземелье) / 57 (дворец),
+то есть **6 пикселей из 64 — впустую, 9,4 % площади heal'а**.
+
+**И обратная сторона, которую тоже надо разобрать.**  Ни 60, ни 64 не
+покрывают того, что перерисовка РИСУЕТ: два полных `draw_tile` красят до
+**90** пикселей (32 свои + 32 соседа + 26 правой грани соседа, уходящей в
+третью клетку).  Видимого артефакта отсюда пока нет — содержимое третьей
+клетки статично и перерисовывается одинаково, а трясущийся сосед накрывает
+эту область своим heal'ом, — но несоответствие «heal уже, чем след» надо
+либо закрыть, либо записать как осознанное.
+
+**Что сделать.**  Свести ВСЕ точечные heal'ы (`pop_loose_shake_draw`,
+`pop_spike_redraw`, `pop_chomp_redraw`, `pop_floor_bake`, `pop_loose_bake_empty`,
+`pop_ceil_*`, коридор `mob_heal_*`) в таблицу «что рисует / что чистит» и
+привести ширину каждого к фактическому следу.  Ширины брать ИЗ АТЛАСА, а не
+из номера клетки — они разные у двух тайлсетов (26 против 25).
+
+**Проверка:** замер 13/23 до/после (heal'ы — зелёная фаза) плюс визуальный
+прогон комнат с плитами, пиками и чомперами: сужение heal'а — самый прямой
+способ получить «недочищенный хвост».
+
+
 ### <a id="l12-shadow"></a>L12-SHADOW. Уровень 12: встреча с тенью, бой, слияние
 
 > **Статус 2026-08-13: код написан, хост-тесты зелёные (45 проверок,