fix(engine): hijack multiplexed listener conn to stop pool-slot leak on reconnect (#3694)

[AlexlaGuardia]

Fixes #3694.

Problem

pkg/repository/multiplexer.go's pgxlisten Connect callback acquires a *pgxpool.Conn and returns its raw *pgx.Conn, letting the pool wrapper fall out of scope without Release():

poolConn, err := m.pool.Acquire(ctx)
if err != nil {
    return nil, err
}
return poolConn.Conn(), nil // *pgxpool.Conn wrapper orphaned, never Release()d

pgxpool keeps counting that slot as acquired. Every time pgxlisten reconnects (server-side idle_session_timeout, pgbouncer server_idle_timeout, or an L7 proxy idle kill), it Close()s the raw conn via its defer, but the orphaned pool slot is never reclaimed. So the pool leaks one slot per reconnect until Acquire() blocks at MaxConns and the control plane wedges.

Fix

Return poolConn.Hijack() instead of poolConn.Conn():

return poolConn.Hijack(), nil

Hijack() transfers ownership of the underlying connection out of the pool and removes it from pgxpool's accounting, so when pgxlisten closes it on reconnect, nothing leaks. pgxlisten already owns the connection's lifecycle (it closes the conn on every reconnect), which is exactly the case Hijack exists for. One-line behavioral change plus an explanatory comment.

Testing

The leak is integration-level: it only manifests across reconnect cycles under server-side idle termination, so it isn't cleanly covered by the existing repository unit tests. I verified the fix by reasoning about pgxpool's ownership semantics (Hijack() is the documented way to remove a connection from the pool permanently). Happy to add an integration test that drives the reconnect path if you'd like one before merge.

AI usage disclosure

Per CONTRIBUTING.md#ai-usage: this fix was implemented with Claude Code (Opus). It traced the leak from the issue through multiplexer.go, implemented the Hijack() change, and reviewed it against the pgxpool API and pgxlisten's connection lifecycle before opening. Same human-directed workflow and disclosure as #4180.

[vercel]

@AlexlaGuardia is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

[gregfurman]

cc @mnafees -- wdyt?