fix(cron): reduce polling interval and recover advance_next_run crash window

[JoaoMarcos44]

Closes #51038

O que aconteceu

Em 22/06/2026, 11 jobs de cron falharam em disparar nos horários agendados. Dois confirmados:

• Daily 1130 — agendado 11:30, nunca disparou (acionado manualmente às 11:53)
• Next Day 1530 — agendado 15:30, nunca disparou (acionado manualmente às 15:43)

Sintoma: next_run_at passou normalmente, mas last_run_at permaneceu null. O clock estava sincronizado via NTP, então não era fuso nem deriva.

---

Investigação

Tracei o fluxo do tick() em cron/scheduler.py:

# (1) advance_next_run para TODOS os jobs devidos ANTES de qualquer execução
for job in due_jobs:
    advance_next_run(job["id"])   # escreve next_run_at = próximo período

# (2) despacha para thread pool
for job in due_jobs:
    _submit_with_guard(job, pool)  # executa → mark_job_run()

Se o gateway crashar entre (1) e (2):

next_run_at = "2026-06-23T11:30:00"   ← advance_next_run já escreveu amanhã
last_run_at = null                     ← mark_job_run nunca rodou

Em todo restart subsequente:
  next_run_dt <= now?  NÃO → get_due_jobs() ignora para sempre

Esse é o crash window do design at-most-once: o advance_next_run protege contra re-disparo em loop, mas cria um ponto cego quando o processo cai entre a escrita e a execução. O intervalo de 60s de polling amplifica a janela — qualquer restart dentro desse minuto bate no problema.

---

Solução

Criei recover_crash_window_jobs() em cron/jobs.py: uma função de recuperação one-shot chamada uma única vez no startup do ticker, antes do primeiro tick. Ela escaneia jobs.json e reseta o next_run_at de qualquer vítima para now, fazendo o primeiro tick normal disparar o job.

Optei por startup-only em vez de inline a cada tick para não tocar no hot-path de get_due_jobs().

Critérios de detecção de vítima — todos precisam ser verdadeiros:

Guard	Motivo
last_run_at = null	job genuinamente nunca rodou
next_run_at > now	já passou pelo filtro normal de due
(next_run_at - now) > grace	suspeito no futuro — advance_next_run já bumpeou pro próximo período
now > first_run_expected	o relógio já passou de quando o job deveria ter rodado pela primeira vez (created_at + interval para interval; croniter.get_next(created_at) para cron)

O guard first_run_expected é o principal antídoto contra falso positivo: um job novo cujo primeiro disparo ainda não chegou nunca é acionado prematuramente.

Também adicionei _resolve_tick_interval() em scheduler_provider.py para tuning via HERMES_CRON_INTERVAL (env var) ou cron.tick_interval_seconds (config.yaml), sem alterar o default de 60s.

---

Testes

Comparei as duas abordagens (inline elif a cada tick vs. startup recovery) com 500 repetições em 100 jobs — diferença de performance dentro do ruído de medição (~1.8ms vs ~2.0ms por call). Escolhi startup recovery por ser mais cirúrgica e não tocar no hot-path.

8 novos testes em TestResolveTickInterval — env var tem prioridade, config fallback, clamping mínimo 5s, valor inválido, default 60s.

4 novos testes em TestGetDueJobs — job resetado quando first_run_expected passou; job intocado quando ainda no futuro; job com last_run_at ignorado; múltiplas vítimas resetadas em um único pass (cobre o cenário de 11 jobs da issue).

Bateria final:

14 failed, 530 passed   ← com o fix (+12 passes líquidos)
14 failed, 513 passed   ← baseline pré-fix

14 falhas são todas pré-existentes: testes de permissão Unix no Windows, croniter/httpx/dotenv ausentes no CI. Zero regressões.