Leader failover never happens -- the outgoing leader never unlocks

Leader election with automatic failover is the headline feature of this project -- the README's entire "kill the leader and watch failover" demo depends on it working. As shipped, it doesn't: every graceful shutdown (a deploy, a rolling restart, a scale-down) permanently leaks the leadership lock. Once that happens, no instance in the cluster can ever become leader again until someone notices cron jobs have stopped materializing and manually intervenes. This turns routine, expected operational events (every deploy) into the trigger for a total, silent outage of the scheduling function, with the API, health checks, and worker pool all reporting healthy the entire time.

pkg/leader/leader.go's release is supposed to unlock the advisory lock before returning the connection to the pool, but the call to SELECT pg_advisory_unlock($1) is missing entirely. e.conn.Release() only returns the connection to the pgxpool's idle pool for reuse -- it does not end the underlying Postgres session, and Postgres advisory locks are held by the session (backend connection) until that session either explicitly unlocks or the connection itself is closed. The lock stays held by a connection the pool now thinks is just an ordinary, available connection.

1. Start an Elector, wait for it to acquire leadership.
2. Cancel its context (simulating graceful shutdown / SIGTERM) and wait for Run to return.
3. From any other connection, call SELECT pg_try_advisory_lock($1) with the same lock ID (pkg/leader.LockID).
4. Observe: it returns false -- the lock is still held -- indefinitely.

This is a case where the comment on the type (Elector -- "Advisory locks in Postgres are session-scoped: they live and die with the connection that took them") correctly describes the semantics, but the code that's supposed to act on that semantic doesn't. pgxpool.Conn.Release() and "the Postgres session that connection represents ends" are two different things, and conflating them is exactly the mistake here.

Compare release to attempt's handling of a dead connection a few lines away -- that path deliberately does not call pg_advisory_unlock (correctly: a dead connection's session, and therefore its lock, is already gone from Postgres's perspective). release's job is the opposite case: the connection is alive and healthy, and we're intentionally choosing to give up the lock, which requires explicitly telling Postgres to release it.