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.

docs/plan-seo.md

@@ -186,7 +186,7 @@
       `+layout.svelte`), а не литералом `/og/…`: под `BASE_PATH` корневой путь
       ломается. Домен для этого не нужен; при деплое на собственном домене
       OG-картинки будут абсолютными и корректными.
-- [ ] **[S1f]** Download-кнопка с селектором формата PNG/JPG/WebP/BMP (+quality
+- [x] **[S1f]** Download-кнопка с селектором формата PNG/JPG/WebP/BMP (+quality
       для lossy) для всех инструментов — механика `Tool.output` уже есть
       (`docs/backlog.md`, «Идеи» №6, UX-райз «Download»). Продуктовая основа
       «image tools»-позиционирования: без неё сайт остаётся PNG-сайтом. Вести
@@ -197,7 +197,9 @@
       что селектор формата его не покрывает.
 - [ ] **[S1g]** Поведение конвертеров после S1f: не предлагать в меню форматов
       формат исходника (disable) — чтобы `convert-png-to-jpg` не мог сохранить в
-      png. Существующие страницы не трогать: `convert-png-to-jpg`,
+      png. **Под вопросом:** блок мешает легальному сценарию «сохранить
+      обработанный PNG / JPEG с другим качеством»; решение не принято, см.
+      `docs/backlog.md`. Существующие страницы не трогать: `convert-png-to-jpg`,
       `convert-png-to-webp`, `png-to-bmp` остаются самостоятельными лендингами
       со своим контентом (§5).
 
@@ -313,6 +315,13 @@
 > смыслу: `round-corners-png` лежит в `alpha`, `add-text-png` и
 > `watermark-tile-png` — в `text`.
 
+> **Открытый вопрос по интенту «сжать до N КБ».** Лимит размера теперь живёт в
+> кнопке Download (`fitWithinBytes` в `web/src/lib/core/io.ts`); интенты вида
+> «compress png to 500kb / 1mb» — high-volume и лимит-ориентированные, селектор
+> в Download их не закрывает как посадочная. Решение (отдельная страница / приём
+> в контенте существующих / ничего) требует вордстата; имя страницы не выбрано.
+> Прорабатывать вместе с вопросом «из формата в PNG» выше.
+
 > **Открытый вопрос по интентам «из формата в PNG».** У конкурента есть
 > `jpg-to-png`, `webp-to-png`, `gif-to-png` как отдельные страницы; у нас таких
 > инструментов нет и создавать их не хочется — загрузка файла уже принимает