v1.46.2: re-check of v1.46.1 — HP-1461-01, -02

HP-1461-01: collection was tied to config/set, which is the right scope for
what a commit supersedes but leaves a file nobody references with no future
write to notice it — cancel a dialog after the upload finished, drop the
connection just after, or call the upload API directly. The daily sweep added
in v1.46.1 only removed streaming temporaries, so the documented 'a cancelled
attachment is collected an hour later' did not hold on an instance nobody
edits. The scheduled pass now loads the stored config under the same write_lock
a commit uses and runs collect_attachments/collect_plans with it as BOTH sides:
nothing counts as superseded, referenced files are preserved, aged unreferenced
ones go. Doing it under the lock keeps it from deciding on a snapshot a commit
is about to replace.

HP-1461-02: _reloadLayoutOnly captured the dirty set AFTER flushing the pending
write, and the flush empties it first — so during a real drag (where a write is
already scheduled) the snapshot was empty and the server's older position was
merged over the user's move. The snapshot is taken before the flush, by value,
and a _sentPos map now holds positions that are sent but unacknowledged, which
closes the same window for a write that was already in flight.

Tests: the upload test now cancels the request task for real (the previous one
claimed to and only walked error paths); smoke_layout_sync schedules a genuine
debounced write and delays it — verified failing on a v1.46.1 build with
exactly the reported symptom; a new backend test reloads the entry and asserts
the scheduled sweep takes an aged cancelled attachment and an orphan plan while
keeping everything the config still references.
Docs: CHANGELOG.md + CHANGELOG.ru.md + ARCHITECTURE.md + TESTING.md + STATUS.md.

docs/ARCHITECTURE.md

@@ -198,8 +198,13 @@ uploads agree on one name and quietly overwrite each other. It also budgets the
 length so the result survives the sanitiser the content view applies to the
 request, since a name the view rewrites is a file written and never served.
 Streaming temporaries live in the files root under `.upload-`, are removed on
-every exit path of the request, and are swept at startup and daily for the
-cases a process death leaves behind. A new icon has no id yet, so its
+every exit path of the request (including cancellation, which is a
+BaseException and slips past `except Exception`), and are swept at startup and
+daily. That scheduled pass also runs the two collectors with the stored
+configuration as *both* sides — nothing superseded, so every referenced file is
+kept and only aged unreferenced ones go. Without it, collection would only ever
+happen when somebody saves, and a file uploaded into a dialog that was then
+cancelled would wait for a write that may never come. A new icon has no id yet, so its
 files go to a per-dialog staging folder and move to the real id once the config
 write is accepted — the same copy → save → cleanup order as a rebind.
 `config/set` collects what its commit superseded, and anything unreferenced and

docs/CHANGELOG.md

@@ -1,5 +1,30 @@
 # Changelog
 
+## v1.46.2 — 2026-07-28 (re-check of v1.46.1: HP-1461-01, -02)
+- **A file nobody ended up using is now cleaned up even if nothing is ever
+  saved again (HP-1461-01).** Collection is tied to a configuration write,
+  which is right for what a write supersedes but leaves a gap: cancel a dialog
+  after the file has already uploaded, lose the connection just after, or call
+  the upload API directly, and nothing references the file and no future write
+  notices it. The daily sweep added in v1.46.1 only removed half-finished
+  transfers, so the promise that a cancelled attachment disappears after an hour
+  did not hold on an instance nobody edits. The sweep now compares against the
+  stored configuration — under the same lock a write uses — and collects aged
+  unreferenced attachments and plans as well.
+- **A drag is no longer undone by someone else's move (HP-1461-02).** When the
+  full card learned to follow position changes in v1.46.1, it protected the
+  positions you had moved but not yet sent — except it read that list *after*
+  flushing the pending write, and flushing empties it first. In a real drag,
+  where a write is already scheduled, the list was therefore empty and the
+  server's older position was painted over your move. The card now takes the
+  snapshot before flushing and also holds on to positions that are sent but not
+  yet acknowledged: until the server confirms a position, the card that moved it
+  is the authority on it.
+- Two tests grew up to their docstrings: the upload test now actually cancels
+  the request task instead of only exercising error paths, and the position-sync
+  smoke schedules a real debounced write and delays it, which is the ordering
+  that lost the drag.
+
 ## v1.46.1 — 2026-07-28 (re-check of v1.46.0: HP-1460-01 … -03)
 - **Two uploads of the same file name can no longer collide (HP-1460-01).**
   v1.46.0 stopped overwriting attachments, but choosing a free name and taking

docs/CHANGELOG.ru.md

@@ -6,6 +6,32 @@
 > **Правило проекта:** оба файла пополняются в одном коммите с самим
 > изменением — как и остальная документация (см. docs/STATUS.md).
 
+## v1.46.2 — 2026-07-28 (перепроверка v1.46.1: HP-1461-01, -02)
+- **Файл, который в итоге никому не понадобился, убирается, даже если больше
+  ничего не сохраняют (HP-1461-01).** Сборка привязана к записи конфигурации —
+  это верно для того, что запись вытесняет, но оставляет зазор: отмените диалог
+  после того, как файл уже загрузился, потеряйте связь сразу после, или
+  вызовите API загрузки напрямую — и на файл никто не ссылается, а будущей
+  записи, которая бы это заметила, нет. Добавленное в v1.46.1 ежедневное
+  подметание убирало только незавершённые передачи, поэтому обещание «отменённое
+  вложение исчезнет через час» не выполнялось там, где никто ничего не правит.
+  Теперь подметание сверяется с сохранённой конфигурацией — под той же
+  блокировкой, что и запись, — и собирает устаревшие непривязанные вложения и
+  планы тоже.
+- **Перетаскивание больше не отменяется чужим перемещением (HP-1461-02).** Когда
+  в v1.46.1 полная карточка научилась следить за позициями, она защищала те,
+  что вы подвинули, но ещё не отправили, — вот только читала этот список *после*
+  сброса отложенной записи, а сброс его первым делом опустошает. При настоящем
+  перетаскивании, когда запись уже запланирована, список оказывался пустым, и
+  старая серверная позиция закрашивала ваше движение. Теперь снимок снимается до
+  сброса, и вдобавок удерживаются позиции, отправленные, но ещё не
+  подтверждённые: пока сервер не подтвердил позицию, авторитет по ней — та
+  карточка, которая её подвинула.
+- Два теста доросли до своих же описаний: тест загрузки теперь действительно
+  отменяет задачу запроса, а не только проходит по путям ошибок, а смоук
+  синхронизации позиций планирует настоящую отложенную запись и задерживает её —
+  именно этот порядок и терял перетаскивание.
+
 ## v1.46.1 — 2026-07-28 (перепроверка v1.46.0: HP-1460-01 … -03)
 - **Две загрузки с одинаковым именем больше не сталкиваются (HP-1460-01).**
   v1.46.0 перестала затирать вложения, но выбор свободного имени и его занятие

docs/STATUS.md

@@ -15,12 +15,12 @@
 
 | Item | State |
 |---|---|
-| Version | **v1.46.1** everywhere (manifest, const.py, package.json, CARD_VERSION); deployed to the home instance |
+| Version | **v1.46.2** everywhere (manifest, const.py, package.json, CARD_VERSION); deployed to the home instance |
 | Workflow | Since 2026-07-22: minor changes go to branch **`dev`** (build + smokes → deploy home → commit → push, NO release); releases are batched on the owner's command (merge dev→main, one tag, one release with a summary changelog, CI checked on dev beforehand) |
 | GitHub | https://github.com/Matysh/houseplan-card — **`main` carries every published release, the latest tag is the current version above**; `dev` is where work lands and is merged into `main` at release time (so `dev` is normally equal to or ahead of `main`, never behind). Push via SSH key `ha_jb` (remote git@github.com:…); API releases via the fine-grained PAT in `~/.git-credentials` (Contents R/W, issued 2026-07-23) |
 | CI | validate.yml (hacs + hassfest + frontend + backend) green; release.yml attaches the bundle on release publish |
 | HACS | Custom repository works. **Inclusion PR: hacs/default#9004** — open, valid, labeled; ~864 older open PRs but merge rate ≈180/mo; realistic ETA 1–3 months (checked 2026-07-24) |
-| Home instance | ha.jbstudio.pro (SSH port 323, key `ha_jb`), deployed **v1.46.1** via direct copy (HACS custom repo also installed) |
+| Home instance | ha.jbstudio.pro (SSH port 323, key `ha_jb`), deployed **v1.46.2** via direct copy (HACS custom repo also installed) |
 | Localization | UI en/ru (src/i18n/*.json), everything user-visible localized incl. kiosk popover |
 | Tests | Four layers: frontend unit (`npm test`, node:test over `test-build/`), pure backend (`pytest tests_backend`, runs anywhere), HA-harness backend (same folder, CI only — needs py3.13 + pytest-homeassistant-custom-component), and browser smokes (`demo/smoke_*.mjs`, headless chromium). **Counts are not written down here** — they went stale within two releases while the version line beside them was kept current, which reads as less coverage than exists (review R5-2). Run `npm run inventory` for the current numbers, or read them off the last CI run |
 | Community | **Telegram chat: https://t.me/ha_houseplan** (created 2026-07-27) — the primary user-facing support channel; GitHub issues stay for bugs/features. Link it from any new release notes and posts |

docs/TESTING.md

@@ -239,6 +239,15 @@ Run the *core flows* (marked ★ below) in each environment at least once per mi
       on the plan after a reload. Same for each tap action and each fill mode
       [auto: backend test_every_display_mode_the_editor_offers_is_accepted and
       neighbours, test_a_marker_showing_its_value_can_be_saved]
+- [ ] Nothing accumulates on an idle instance (v1.46.2, HP-1461-01): attach a
+      file, cancel the dialog, and do not save anything else — an hour later (or
+      after a restart) the file is gone, while every file the configuration
+      still references is untouched
+      [auto: backend test_scheduled_sweep_collects_what_no_commit_will]
+- [ ] A drag wins over a concurrent remote move (v1.46.2, HP-1461-02): drag an
+      icon and, while the save is still in flight, have another window move a
+      different icon — your icon stays where you put it and the other one
+      updates [auto: smoke_layout_sync]
 - [ ] Concurrent uploads of one name (v1.46.1, HP-1460-01): attach the same
       file from two browser tabs at once — two attachments, two sets of bytes,
       neither lost. A file whose name is at the length limit still downloads