[Идея]: Миграция на инфраструктурата към AWS (Lambda + S3-SQLite + CloudFront)

[Zhivkot]

Какъв проблем решава

Няколко документирани пропуска в текущата архитектура, които собственият ни RFC
(docs/etl-architecture.md) иска да реши, но D1
платформата прави трудни или невъзможни:

• Автономният cron refresh е без предпазна мрежа — пише директно в живата база без
  integrity gate (feat(etl): граница на публикуване (staging → assertIntegrity → promote) за cron пътя #163) и без FX курсове (feat(etl): cron refresh не зарежда FX курсове — договорите в чужда валута получават NULL amount_eur #158); gate-ът на останалите пътища е post-publish
  („ship-and-alert", Данни: твърди проверки за цялост в pipeline-а (reconciliation gate) #97) — грешни числа вече се обслужват, когато алармата звънне.
• Няма rollback за пътя, който върви без надзор — blue/green слотовете (ADR-0005) покриват
  само пълните reseeds; 6-часовият refresh презаписва живото на място.
• Няма purge hook при опресняване — на *.workers.dev edge кешът е непречистваем; след
  reseed страници могат да показват стари данни (вкл. нули) до ~1 час.
• Няма RAW архив — суровите дневни файлове живеят само на storage.eop.bg + локален кеш на
  нечий лаптоп; replay/debug на минал ден зависи от външния източник.
• Платформени тавани на D1 — ~30 s per-query CPU лимитът наложи цялата chunked-ship
  архитектура на ship-domain.mjs; 10 GB таван; ~20-минутни bulk зареждания.

Предложение

Направих feasibility анализ с целева архитектура (диаграмата е прикачена):

Lambda + SQLite файл в S3 + CloudFront — без управлявана база. ETL-ът строи целия обслужван
SQLite файл офлайн (същият гейтван work-DB pipeline, който вече имаме — import.mjs), пуска
assertIntegrity върху файла преди каквото и да е качване, качва го като нова S3 версия и
промотира с флип на един SSM указател. SSR Lambda тегли живата версия в /tmp и чете локално
през node:sqlite.

Какво дава:

• Един гейтван ETL път вместо два — pre-publish gate на всеки refresh; Данни: твърди проверки за цялост в pipeline-а (reconciliation gate) #97/feat(etl): cron refresh не зарежда FX курсове — договорите в чужда валута получават NULL amount_eur #158/feat(etl): граница на публикуване (staging → assertIntegrity → promote) за cron пътя #163 се
  затварят по конструкция; провален gate не качва нищо.
• Rollback с един флип за всеки refresh (не само reseeds), без redeploy; историята на
  указателя е одитен дневник.
• RAW зона в S3 (90-дневен lifecycle, ~$1/мес) + CloudFront invalidation като стъпка от
  промоцията.

Алтернативи (по желание)

No response

Преди да изпратите

• Проверих docs/ и съществуващите issue-та за нещо подобно.