na-report: journalctl -k читает только текущий бут — после ребута отчёт занижает события в разы (2 298 против 72 485) #41

Что происходит

na-report собирает события из journalctl -k, а -k подразумевает -b (только текущая загрузка).
Окно задаётся через --since -Nh, поэтому после перезагрузки отчёт молча показывает не «за 24 часа»,
а «с момента ребута» — и занижает всё: число дропов, топ источников, вердикты.

Строка: scripts/na-report.sh:59

journalctl -k --since "-${HOURS}h" --no-pager -o short-unix 2>/dev/null \
  | grep -aF '[na ' \

Тот же дефект у ветки --port (na-report.sh:325).

Наблюдалось

2026-08-31, флот из 5 нод, разбор сразу после планового ребута. На de01 na-report за 24 ч дал
2 298 событий, при том что реально их было 72 485:

$ na-report | head -3
[*] Окно: последние 24ч · событий в drop-логе: 2298
$ journalctl -k -b all --since -24h | grep -c '\[na '
72485

Разница ×31 — то есть в первые сутки после любого ребута отчёт бесполезен именно тогда, когда в него
чаще всего и смотрят. Сегодня, спустя двое суток аптайма, оба числа совпали (74 941 / 74 941), поэтому
на живой ноде дефект незаметен и всплывает только рядом с перезагрузкой.

Предлагаемый фикс

• Добавить -b all в оба вызова (collect_events и ветка --port). При --since это корректно:
  граница по времени сохраняется, а границы бута перестают резать окно.
• Если -b all нежелателен по производительности на больших журналах — хотя бы предупреждать в шапке:
  «аптайм < окна отчёта: показаны события с момента загрузки (Nч), а не за Nч».
• Заодно в шапку отчёта стоит вывести фактическую глубину журнала (самая старая запись) — сейчас
  оператор не отличает «атак не было» от «журнал уже вытеснен» (смежно с protect/optimize: лог анти-скана 5/сек против journald SystemMaxUse=300M — на публичной ноде журнал живёт меньше суток #35).