A shutdown/ticker scheduling race can leak the leadership lock

This is the subtlest bug in the set: it doesn't reproduce every time, which is exactly what makes it dangerous in production. A leader that steps down (graceful shutdown, deploy, rolling restart) will usually release the lock cleanly -- but on an unlucky timing coincidence between its own poll ticker and the shutdown signal, it can leak the lock instead, leaving the cluster with no cron-materialization leader until the leaked connection eventually times out or the process restarts again. Because it's intermittent, this is the kind of bug that passes staging and most production deploys, and then one day, during exactly the kind of high-traffic rolling restart where reliable failover matters most, no instance ever picks up leadership and every cron job silently stops materializing new runs.

pkg/leader/leader.go's Elector.Run loop selects between ctx.Done() and ticker.C. attempt uses the loop's own ctx (the one that gets cancelled on shutdown) for its connection health check: e.conn.Ping(ctx). When ctx is cancelled at almost exactly the moment the ticker also fires, Go's select has no defined preference between two simultaneously-ready cases -- it can pick the ticker.C branch instead of returning, running attempt one more time with an already-cancelled (or about-to-be-cancelled) ctx. Ping(ctx) then fails because ctx is done, not because the connection actually died -- but attempt can't tell the two apart, so it takes the "the connection is presumably dead, don't bother unlocking" branch. The still perfectly-healthy connection goes back to the pool with the advisory lock silently still held on it.

This is a genuine race, not a one-shot reproduction -- the dedicated test uses a very fast tick (2ms) and repeats the acquire-then-cancel cycle 40 times to make hitting the race close to certain.

This is a real example of conflating two different meanings of "context cancelled": "the operation should stop because the caller gave up" versus "the operation failed because something is actually broken." Ping can't distinguish them from the returned error alone -- the caller has to pass a context that only carries the second meaning.

attempt already creates a short-lived, independent context (qCtx) for exactly this reason, and uses it for the pool.Acquire and pg_try_advisory_lock calls further down. Check which context the Ping call a few lines above those is using.