fix(ods): изменен батчевый резолвер для транзакционных таблиц

- Зачем:
  - текущая реализация ODS batch_id теряла данные транзакционных таблиц, если между запусками ODS STG успевал отработать дважды (брался только последний батч).
- Что:
  - изменены скрипты загрузки транзакционных таблиц (bookings, tickets, flights, segments, boarding_passes) для использования паттерна HWM по _load_ts вместо фильтрации по конкретному батчу.
  - обновлен комментарий в DAG bookings_to_gp_ods, объясняющий разное поведение для справочников и транзакционных данных.
  - сохранено использование оригинального batch_id из STG для поля _load_id в слое ODS для сквозного трассирования.
- Проверка:
  - запуск пайплайнов и проверка, что все батчи загружаются из STG в ODS без потерь.

airflow/dags/bookings_to_gp_ods.py

@@ -34,6 +34,15 @@ def _resolve_stg_batch_id(**context) -> str:
     """
     Возвращает stg_batch_id из dag_run.conf или вычисляет последний согласованный батч.
 
+    ВНИМАНИЕ: Это значение используется ТОЛЬКО для загрузки snapshot-справочников
+    (airports, airplanes, routes, seats). 
+    
+    Для инкрементальных транзакционных таблиц (bookings, tickets, flights, segments,
+    boarding_passes) этот батч НЕ используется. Вместо этого они грузят все новые 
+    записи по HWM: WHERE load_dttm > (SELECT MAX(_load_ts) FROM ods.table).
+    Это сделано для того, чтобы не потерять инкременты, если STG-DAG запускался 
+    несколько раз до запуска ODS-DAG'а.
+
     Зачем нужна согласованность (INTERSECT по всем справочникам)?
     Чтобы ODS загружал только те данные, для которых уже приехали ВСЕ связанные
     справочники. Это защищает от рассинхрона данных, когда часть измерений в текущем