Reconcile automations when Postgres notifications are unavailable

[zzstoatzz]

closes #21083

this PR reconciles automations from the database when the triggers service cannot rely on PostgreSQL notifications alone.

Details

• add a lightweight automation state snapshot and periodic reconciliation in the triggers service
• keep the existing NOTIFY/LISTEN path as the fast path, but recover on startup, reconnect, and periodic evaluation
• add trigger service tests for snapshot-based reconciliation behavior

Manual verification:

• reproduced the failure locally with the full stack using Postgres + Redis + pgbouncer in transaction pooling mode
• confirmed backend Postgres had 0 LISTEN "prefect_automation_changes" sessions in that topology
• verified that, without restarting prefect server services, a newly created automation was picked up by reconciliation and emitted event traffic created a deployment flow run

Automated verification:

• uv run pytest tests/events/server/triggers/test_service.py tests/events/server/triggers/test_service_changes.py
• uv run ruff check src/prefect/server/events/triggers.py tests/events/server/triggers/test_service.py

[codspeed-hq]

Merging this PR will not alter performance

✅ 2 untouched benchmarks

---

_{Comparing codex/21083-pgbouncer-automation-reconcile (0705a38) with main (c796a54)¹}

Footnotes

1. No successful run was found on main (0b734db) during the generation of this report, so c796a54 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[chrisguidry]

Makes sense to me! Would love to understand why the LISTEN/NOTIFY didn't work, is it more that things drift over time?

[zzstoatzz]

Would love to understand why the LISTEN/NOTIFY didn't work, is it more that things drift over time?

since LISTEN/NOTIFY is session-based, and pgbouncer transaction pooling does not preserve a stable pg session, i was able to repro that the listener was never reliably active in setups including pgbouncer