P2 — drift hazard + over-broad catch. The connection-dead tuple (psycopg2.OperationalError, psycopg2.InterfaceError) is now inlined in two coupled sites: here and in _cursor (isinstance(exc, (...)), line 122-124). They must stay in lockstep — narrowing one without the other silently breaks the retry's "was this a connection death?" test. The sibling client.py (UN-3654) deliberately hoisted this into a named _CONN_DEAD_ERRORS: Final[tuple[...]] = (...) constant precisely to prevent this, with a comment to that effect. This PR re-introduces the duplication the sibling removed. Suggest mirroring it:

_CONN_DEAD_ERRORS: Final[tuple[type[Exception], ...]] = (
    psycopg2.OperationalError, psycopg2.InterfaceError,
)

then except _CONN_DEAD_ERRORS as exc: here and isinstance(exc, _CONN_DEAD_ERRORS) in _cursor.

Secondary (P3): OperationalError is also the base class for deadlock/serialization (class 40), statement-timeout/cancel, and disk-full/too-many-connections (class 53). Those will trip this retry + the 0.5s sleep and tear down a healthy cached connection, while being logged as "stale idle reap or DB unavailable" — a misleading label for a deadlock. Idempotency keeps it correctness-safe, but consider either softening the warning wording to describe what was observed rather than an inferred cause, or gating the retry on exc.pgcode SQLSTATE class 08 (plus InterfaceError, which has no pgcode).

P3 — retry is a silent no-op for injected (non-owned) connections. _cursor only discards the dead handle when self._owns_conn (line 136). For an injected connection (_owns_conn=False), self._conn is not cleared on a connection-level error, so attempt 2 re-acquires the same dead handle via self.conn, burns the 0.5s backoff, fails identically, and re-raises — the retry buys nothing. Production is safe (the executor consumer always constructs PgResultBackend() with _owns_conn=True), but the asymmetry is undocumented. Either short-circuit if not self._owns_conn to raise immediately without the spurious sleep, or add a one-line note that the retry only heals owned connections. (Relatedly, the docstring's "_cursor has already dropped the handle" at line 152-153 is only true for owned connections — worth a half-clause clarifying that.)

P3 — comment-rot trap. This says the retry is omitted because "the only caller, executor_rpc.wait_for_result, makes a FRESH PgResultBackend per wait." Two precisions: (1) get_result's direct caller is PgResultBackend.wait_for_result (same class); executor_rpc.wait_for_result is the reachable entry point two hops up. (2) This is a load-bearing "only caller" safety assertion — if someone later adds a one-shot get_result lookup on a long-lived backend, the rationale silently goes stale. Suggest rewording to the invariant it actually depends on, e.g. "the sole entry point creates a fresh backend per wait and polls it every ~0.2–2s, so the connection is new and kept warm." The 0.2–2s figures and "fresh per wait" themselves check out.

P2 — no CI test proves the reconnect actually heals against real PG. Every test here drives failure through cur.execute.side_effect against a fully mocked conn/cursor/create_pg_connection, asserting orchestration (close/factory/execute/commit were called). If _cursor's discard stopped nulling self._conn, or the real reconnect produced an unusable handle, these would still pass. The genuine heal is only covered by the manual pg_terminate_backend dev-test, which is not in CI. Consider one DB-gated test (no pg_terminate_backend needed — a client-side close() makes psycopg2 raise InterfaceError on next use):

rb = PgResultBackend()          # owned, real factory
rb.conn                          # materialize
rb._conn.close()                 # next use -> InterfaceError
rb.store_result(k, result={"healed": True})   # must self-heal
# then assert the row landed via a fresh backend's get_result

This is the test that would actually fail if the reconnect were broken.

P3 — two retry-path gaps worth closing. (1) Failed-status branch is never retried: all six tests call store_result(..., result={...}) (completed branch); the result is None -> STATUS_FAILED path is only covered by the no-retry real-PG round-trip. Since the PR's whole motivation is "a failed task's result silently dropped -> caller stranded," delivering the failed outcome through a stale connection deserves coverage — easily added by parametrizing this test over {"result": {...}} and {"error": "boom"}. (2) Commit-time reap untested: _cursor commits after the yield, and an idle reap typically surfaces when the buffered INSERT flushes at conn.commit(), not at execute. A variant with conn.commit.side_effect = OperationalError(...) on attempt 1 (fresh conn succeeds) would cover the most realistic failure point.