feat: add limit size to download flow

docs/backlog.md

@@ -86,15 +86,42 @@
 - [ ] **Идея 6. Конвертация формата — НЕ отдельный инструмент, а выбор в кнопке
       Download** — оценка M/L. Решение и продуктовое обоснование:
       `docs/plan-seo.md` §0 и задача **S1f**; почему селектор не заменяет
-      существующие convert-страницы — `docs/plan-seo.md` §5. Механическая часть
-      уже есть: `Tool.output` (`OutputFormat`: mime/ext/qualityParamId) и
-      кодирование по нему в `SchemaToolView.download()` —
-      `docs/architecture.md`, раздел 3. Что осталось сверх S1f: - экспорт с
-      лимитом размера → «сжатие до целевого КБ»: для lossy это quality в
-      селекторе формата, для PNG — бинарный поиск по k из квантования. Нужна ли
-      отдельная страница под этот интент — открытый вопрос с вордстатом, имя не
-      выбрано (`docs/plan-seo.md` §5). Проработать вместе с достройкой
-      download-флоу.
+      существующие convert-страницы — `docs/plan-seo.md` §5. Селектор формата и
+      качества в Download уже есть; «сжатие до целевого КБ» реализовано
+      (`fitWithinBytes` в `web/src/lib/core/io.ts`: бинарный поиск по quality
+      для lossy, по k квантования для PNG; для BMP — предупреждение, что лимит
+      не применим). Что осталось: нужна ли отдельная страница под интент «сжать
+      до N КБ» — открытый вопрос с вордстатом, имя не выбрано
+      (`docs/plan-seo.md` §5). Проработать вместе с достройкой download-флоу.
+- [ ] **S1g под вопросом** — исходная формулировка (`docs/plan-seo.md` §4): на
+      convert-страницах блокировать в меню Download формат исходника, чтобы
+      `convert-png-to-jpg` не сохранял в png. Против: пользователь может
+      захотеть сохранить обработанный PNG или JPEG с другим качеством — блок
+      мешает легальному сценарию. Решение не принято; перед реализацией
+      переобдумать.
+- [ ] **Лимит КБ: сигнал о недостижимости** — если даже минимальное качество /
+      k=2 не влезает в лимит, файл скачивается молча с превышением. Нужно:
+      `fitWithinBytes` (`web/src/lib/core/io.ts`) возвращает также достигнутый
+      размер, UI показывает warning «не удалось ужаться до N КБ, получилось M».
+- [ ] **Лимит КБ: индикация активного сжатия** — сейчас заданный лимит никак не
+      виден, пока меню Download закрыто: пользователь может забыть про него и
+      случайно сжать следующие файлы. Нужен постоянный индикатор (значок/
+      подпись на кнопке или рядом). Связанный вопрос персистентности: лимит —
+      `$state` в `SchemaToolView.svelte`, при переходе на другой инструмент
+      сбрасывается в `init()` и в localStorage не пишется (в отличие от шагов
+      цепочки). Это безопасное поведение по умолчанию, но стоит осознанно
+      решить: оставить сброс при смене страницы или сохранять лимит (per-tool?
+      глобально?) вместе с цепочкой.
+- [ ] **Лимит КБ/качество: превью итогового результата** — обдумать UI/UX: при
+      сжатии по размеру или низкому качеству дать возможность посмотреть
+      итоговый файл до скачивания — при сильном сжатии (низкий quality, грубое
+      квантование в PNG) искажения могут быть настолько заметны, что
+      пользователь откажется от варианта и выберет другой формат/лимит. Сейчас
+      превью показывает результат инструмента до re-encode, а сжатая версия
+      существует только внутри `fitWithinBytes`/`encode` в момент скачивания.
+      Открытые вопросы: превью на лету (дорого — encode на каждый ввод) или по
+      кнопке «предпросмотр»; где показывать (оверлей/замена тайла результата);
+      связь с идеей 14 (отображение маски) и пунктом про зум превью выше.
 - [ ] **Идея 7. Страница `watermark-image-png` (водяной знак картинкой)** —
       оценка M. Нужна overlay-механика: второй источник изображения
       (getOverlay/store), параметры scale/opacity/position/margin/aspect.