Нарезка задач под целевое состояние: PWA, вход, хранилище

Роадмап: web-access переименована под приложение, которое ставится на
телефон; заведена цель ready-notification — уведомление о готовности
без открытого приложения.

Беклог: десять задач. Многопользовательская цепочка (oidc-login,
record-ownership, telegram-account-link), веб (json-api-for-spa,
spa-skeleton, upload-and-status-screen, records-list-screen,
installable-pwa), уведомления через apprise и ntfy, разведка выбора
фреймворка. Очередь: долги, хранилище, вход, приложение.

Решение сменилось с htmx на SPA, поэтому conventions/web-ui.md снята
целиком и оставлена честной строкой до итога разведки. Открытые вопросы
архитектуры, границы паспорта и триггеры метки ревью приведены в
соответствие.

tasks/items/ready-notification.md

@@ -0,0 +1,25 @@
+# 🎯 Пользователь узнаёт о готовности текста, не держа приложение открытым
+
+- **Тип:** goal
+- **Секция:** Запланировано
+- **Зачем:** Расшифровка занимает минуты, и всё это время человек либо смотрит на экран с опросом статуса, либо забывает вернуться.
+
+Задача уходит в работу — человек закрывает приложение и получает сообщение,
+когда текст готов. Пользователь Telegram это уже имеет: бот отвечает сам.
+Пользователь веба — нет.
+
+Доставку берём внешнюю: apprise как отправитель, ntfy как канал. Web Push с
+VAPID и собственным хранением подписок за целью **не стоит** — это отдельная
+инфраструктура ради того же результата.
+
+## Завершение
+
+1. Готовый текст доходит до пользователя веба сообщением, без открытого
+   приложения.
+2. Отказ задачи доходит тем же путём и тем же человекочитаемым текстом, что
+   видит пользователь Telegram.
+3. Адрес канала уведомлений задаёт пользователь, а не общий конфиг: у каждого
+   свой.
+4. Недоступность канала уведомлений не роняет задачу и не мешает ей завершиться:
+   текст остаётся в приложении.
+5. Пользователь Telegram получает ответ по-прежнему ботом, а не вторым каналом.