ingest: add status history support and drop status_at_collection

docs/INTEGRATION_GUIDE.md

@@ -8,7 +8,7 @@
 
 ## Принципы импорта
 
-1. **Snapshot данных** - JSON содержит состояние сервера на момент сбора, без исторической информации
+1. **Snapshot данных** - JSON содержит состояние сервера на момент сбора и может включать историю изменений статуса компонентов
 2. **Автоматическое определение LOT** - классификация компонентов определяется приложением на основе vendor/model/type
 3. **Статус компонентов** - каждый компонент имеет статус работоспособности (OK, Warning, Critical, Unknown) и может передавать время проверки статуса
 4. **Идемпотентность** - повторный импорт с тем же snapshot не создает дубликаты
@@ -58,8 +58,24 @@
 Для секций `cpus`, `memory`, `storage`, `pcie_devices`, `power_supplies` поддерживается дополнительное поле:
 
 - `status_checked_at` (string RFC3339, опционально) - дата/время, когда был проверен статус работоспособности компонента
+- `status_changed_at` (string RFC3339, опционально) - дата/время последнего изменения статуса компонента
+- `status_history` (array, опционально) - история статусов компонента:
+  - `status` (string) - статус (`OK`, `Warning`, `Critical`, `Unknown`, `Empty`)
+  - `changed_at` (string RFC3339) - дата/время смены статуса
+  - `details` (string, опционально) - пояснение к переходу статуса
 - `error_description` (string, опционально) - текст ошибки/диагностики для статуса компонента (например при `Warning`/`Critical`)
 
+### Правила экспорта JSON для внешнего проекта
+
+Используйте эти правила, если JSON формируется внешним сервисом/экспортером:
+
+1. Всегда передавайте `status` как текущее состояние компонента в snapshot.
+2. Если есть точное время последней смены, передавайте `status_changed_at` (RFC3339, UTC).
+3. Если источник хранит историю (например Windows Event Log), передавайте `status_history` отсортированным по `changed_at` по возрастанию.
+4. В `status_history` не отправляйте записи без `changed_at`; такие записи игнорируются.
+5. Для совместимости допускается передавать только старые поля (`status`, `status_checked_at`) без истории.
+6. Все даты/время в исторических полях должны быть RFC3339; рекомендуется использовать UTC (`Z`).
+
 ---
 
 ## Секция hardware
@@ -889,7 +905,7 @@ Content-Type: application/json
 }
 ```
 
-### Пример 2: Server с отказавшим диском
+### Пример 2: Server с историей "сломан -> починен"
 
 ```json
 {
@@ -910,8 +926,20 @@ Content-Type: application/json
         "firmware": "9CV10510",
         "interface": "NVMe",
         "present": true,
-        "status": "Critical",
-        "error_description": "Error Code on GPU 0 [18:00.0] (S/N 1653925025827) = 020000190097 (unexpected device interrupts)"
+        "status": "OK",
+        "status_changed_at": "2026-02-10T15:22:00Z",
+        "status_history": [
+          {
+            "status": "Critical",
+            "changed_at": "2026-02-10T15:10:00Z",
+            "details": "I/O timeout on NVMe queue 3"
+          },
+          {
+            "status": "OK",
+            "changed_at": "2026-02-10T15:22:00Z",
+            "details": "Recovered after controller reset"
+          }
+        ]
       },
       {
         "slot": "Disk.Bay.1",
@@ -929,9 +957,9 @@ Content-Type: application/json
 ```
 
 **Обработка:**
-- Disk.Bay.0 получит статус Critical
-- Автоматически создастся failure_event для компонента S5GUNG0N123456
-- Timeline event COMPONENT_FAILED
+- Disk.Bay.0 получит текущий статус `OK`
+- История статусов сохранится в `observations.details.status_history`
+- Автоматический `failure_event` не создается, так как текущий статус snapshot не `Critical`
 
 ### Пример 3: Замена памяти