Add Postgres LISTEN/NOTIFY so pollers wake up immediately

Right now, a newly materialized job_run waits out the worker's IDLE_POLL_INTERVAL (default 3 seconds) before any instance notices it if all workers happened to just poll and find nothing. For most jobs this delay is invisible, but for POST /v1/jobs/{id}/trigger -- explicitly documented as the way to fire an immediate one-off run so a demo doesn't require waiting on a real cron interval -- a multi-second delay before it actually starts undercuts the whole point of the endpoint. At larger scale, shortening IDLE_POLL_INTERVAL to compensate means every idle instance hits the database far more often for no reason, trading latency for load in the wrong direction.

pkg/notify/notify.go exists with a single placeholder function, Listen, that panics with "TODO(ticket-E6): Listen not implemented". Nothing in pkg/worker or pkg/queue calls it yet.

1. Call notify.Listen(ctx, pool, "some_channel").
2. Observe: an error resulting from the placeholder's panic, instead of a usable notification channel.

This is the hardest ticket in the set because LISTEN shares an unusual property with the advisory lock in pkg/leader: it is session-scoped. A LISTEN issued on one connection is meaningless if that connection gets returned to a pool and reused for something else -- the subscription lives and dies with that one specific backend connection, exactly like pg_try_advisory_lock. Implementing this correctly requires checking out a dedicated connection (not the shared query pool) and keeping it alive for as long as the caller wants to keep listening, then cleanly releasing it when ctx is cancelled.

Read pkg/leader/leader.go's Elector for the "dedicated connection checked out of the pool, held for the lifetime of the thing, released on context cancellation" pattern -- the shape is very similar here. For the actual wait loop, pgx's connection type exposes a method for blocking until a notification arrives (or the context is cancelled) on a LISTEN-ed connection; look for it on the type you get back from checking out a raw connection (as opposed to a pooled one) -- that method already respects context cancellation internally.