Stop the import listener idling in a transaction, which ate its NOTIFYs

[SiteRelEnby]

The leader-election idle-in-transaction fix had a twin, and this one was not only an observability problem.

The bug

_listen_for_enqueues held a plain engine.connect() for the lifetime of the process and probed it with SELECT 1 every 60 seconds. In the default isolation level SQLAlchemy autobegins a transaction on the first statement, nothing ever ends it, and the heartbeat keeps outrunning idle_in_transaction_session_timeout. Identical to what the leader loop was doing, with the same consequences: it pinned pg_stat_activity's max transaction age to the process uptime, which makes a long-transaction alert impossible to set.

It also broke the feature

Postgres delivers NOTIFY to a listening backend only while that backend is idle. A listener parked inside a transaction that never ends therefore stops receiving notifications altogether.

So from 60 seconds after startup, the enqueue accelerator silently did nothing, and every queued import waited out import_runner_interval_seconds (default 5s) instead of starting in milliseconds.

Nothing was ever lost or stuck. The timed poll is the documented safety net and always picked the job up, which is exactly why this went unnoticed: the symptom was "imports feel slightly slow", not "imports are broken".

Verified directly against a real Postgres, mirroring the production code path, before changing anything:

default (current code):   notify=NOT DELIVERED (timed out after 5s)
AUTOCOMMIT (the fix):     notify=DELIVERED

The fix

One line, matching leader.py: run the listener connection with isolation_level="AUTOCOMMIT". The LISTEN registration belongs to the session rather than the transaction, exactly like the leader's advisory lock, so nothing else about the listener or its reconnect path changes.

Why the existing test missed it

test_enqueue_notify_wakes_the_listener notifies within a few seconds of starting the listener, so the first heartbeat has not run and no transaction has been opened. It passes on the broken code and on the fixed code.

The new test drives several heartbeats before notifying, and fails with a timeout on the old code. That is what the new _LISTEN_HEARTBEAT_SECONDS module constant is for: the bug only exists after the first probe, so a test has to be able to turn the interval down.