doc(HISTORY): п.2 сделан; п.4 — открытая развилка (NOT NULL vs nullable+удалить legacy)

HISTORY/2026-10-07-session-log.md

@@ -129,5 +129,24 @@
 - Закрыто замеченное залипание: один «ядовитый» payload больше не зацикливает
   flush namespace навсегда.
 
+### Реализовано (п.2) — `ts` = время приёма (`a386d22`)
+- `iot_telemetry_store.go`: `telemetryInsert` получил `ts`; `flushTenant` пишет
+  `ts` явно из `ReceivedAt` (серверное время приёма, ставит bridge), а не `now()`
+  БД. Zero → `now()`. Схема не менялась (существующая колонка `ts`).
+- Callers обновлены: `consumer/processor.go` (парсит `ReceivedAt`), legacy
+  `cmd/sqs-consumer`.
+
+### ОТКРЫТО (п.4) — `message_id NOT NULL` / дедуп legacy
+- Проблема: `UNIQUE(device_id, message_id)` не ловит NULL → legacy
+  `cmd/sqs-consumer` (передаёт `""`) не дедуплицируется; возможны дубли.
+- Развилка, где я не уверен (ОСТАНОВКА, без догадок):
+  1. Сделать `message_id NOT NULL`: нужна миграция (backfill `legacy-'||id` +
+     `SET NOT NULL`). Безопасна, но legacy-консьюмер тогда должен передавать
+     SQS `MessageId` (иначе его строки не пройдут NOT NULL и будут «дропнуты»
+     как permanent). Legacy и так идёт под удаление (P2-14).
+  2. Оставить nullable, задокументировать отсутствие дедупа для legacy и
+     удалить legacy (P2-14). Минимальный риск, но формально «не NOT NULL».
+- Нужно решение владельца.
+
 ## Проверки
 - `go build ./...` и `go vet ./internal/...` — зелёные на каждом шаге.