feat(sql): явное управление storage и автоматизированный E2E-тест через REST API

- Зачем:
  - необходимо визуализировать выбор типа хранения (Heap vs Append-Only) для учебных целей.
  - автоматизировать проверку всей цепочки DWH для исключения ручных ошибок.
  - сделать процесс отладки прозрачным и наглядным через стандартные инструменты Airflow.
- Что:
  - внедрена клауза WITH (appendonly=...) во все DDL; ODS-справочники переведены на AO Row и TRUNCATE+INSERT.
  - создан скрипт scripts/e2e_etl.sh для полного прогона ETL (DDL + 2 дня данных) через REST API.
  - исправлены баги типизации (INTEGER[]), именования полей (amount, passenger_id) и удалены фантомные колонки (contact_data).
  - обновлен e2e-etl-test-protocol.md: добавлен раздел по отладке, чтению логов и перезапуску задач через API.
  - исправлены pytest-контракты под новую логику загрузки.
- Проверка:
  - успешный прогон `make e2e-smoke` (полный цикл от очистки до витрины).

sql/dds/fact_flight_sales_ddl.sql

@@ -6,6 +6,10 @@ CREATE SCHEMA IF NOT EXISTS dds;
 -- В классическом DWH (Кимбалл) таблица фактов идентифицируется набором её 
 -- измерений или дегенеративных ключей (в нашем случае: ticket_no + flight_id).
 -- Добавление отдельного ID только тратит место и не несёт аналитической ценности.
+
+-- Тип таблицы: Heap (стандартная).
+-- Обоснование: Необходим row-level UPDATE для обновления статусов (is_boarded).
+-- Использование Append-Only при частых обновлениях приводит к раздуванию (bloat) таблицы.
 CREATE TABLE IF NOT EXISTS dds.fact_flight_sales (
     calendar_sk          INTEGER,
     departure_airport_sk INTEGER,
@@ -24,4 +28,7 @@ CREATE TABLE IF NOT EXISTS dds.fact_flight_sales (
     _load_id             TEXT NOT NULL,
     _load_ts             TIMESTAMP NOT NULL DEFAULT now()
 )
+WITH (appendonly=false)
 DISTRIBUTED BY (ticket_no);
+
+COMMENT ON TABLE dds.fact_flight_sales IS 'Факт продаж билетов (DDS).';