02 - BLOCKER A: qt001_cp_owner Operational Unreachability (in-blueprint)

Codex recheck-2 finding

Owner-transfer off directus was accepted, but Codex requires proof that the new owner qt001_cp_owner is operationally unreachable — otherwise the owner-implicit EXECUTE is merely relocated to a reachable principal. An operator normally needs SET ROLE membership or superuser authority to ALTER ... OWNER, so that path must be explicitly controlled and guard-verified (recheck-2 doc 01 + doc 07).

Live evidence (read-only, DB directus, 2026-06-08, query_pg on pg_roles)

role	rolsuper	rolinherit	rolcanlogin	rolbypassrls	implication
directus	false	true	true	false	non-superuser; after owner-transfer it is non-owner AND non-superuser → effective EXECUTE reachable to 0
workflow_admin	true	true	true	true	cluster superuser, login-capable; outside ACL-zero (blocker F, doc 07)
qt001_cp_owner / migrator / reader	(absent)	—	—	—	MISSING_ADD; the blueprint specifies their attributes at creation

The fix — G-OWNER-UNREACHABLE + role-attribute specification (blueprint docs 04, 06, 08)

The new owner role is created with attributes that make it operationally unreachable, and a guard verifies them over the live catalog:

1. NOLOGIN + non-superuser. CREATE ROLE qt001_cp_owner NOLOGIN is already in the approved DDL (CP-01 §2.1); it is not a superuser. So it has no password/login path and bypasses no ACL.
2. No inbound membership from any login role. pg_auth_members must contain no direct or transitive edge granting qt001_cp_owner to directus, any runtime/app role, or any other rolcanlogin role. Therefore no login principal can SET ROLE qt001_cp_owner, and the owner-implicit EXECUTE is held by a principal nobody can assume.
3. SET ROLE only via the sealed Level-B execution identity. The single sanctioned way to act as the owner is the Level-B migrator/owner principal — principal_registry.auth_db_role bound to a verified human_identity_registry row of the required principal_class (CP-09), used only inside an authorized cutover transaction. This is the existing approved Level-B binding model, not a new surface.
4. Owner holds no grants to any login role (defence in depth so the owner can't be reached by a future grant chain).
5. Superuser is dispositioned separately. workflow_admin is the break-glass concern of blocker F (doc 07); it is excluded from this guard's "unreachable" claim and handled as operator-gated break-glass.

G-OWNER-UNREACHABLE (doc 06) reads pg_roles (the owner's rolcanlogin/rolsuper) and the pg_auth_members transitive closure into qt001_cp_owner, and FAILS if any login role can reach it or if the only-Level-B path is not satisfied. Guard-quality rule: a guard that asserts "legacy effective EXECUTE = 0" while the owner role is reachable is itself a defect.

PG-native, no new surface

This is a guard over existing catalog facts (pg_roles, pg_auth_members) plus the already-approved NOLOGIN role (CP-01 §2.1) and the already-approved Level-B principal model (CP-09). It adds no authority surface, no column, no catalog family, no hash contract — only one new test/verification guard.

Self-check

PASS only if the new owner cannot be reached by any login principal and the only act-as-owner path is the sealed Level-B identity. PASS — NOLOGIN + non-superuser + no inbound pg_auth_members membership + Level-B-only SET ROLE, verified by G-OWNER-UNREACHABLE. The owner-implicit EXECUTE that remains after the S15.1 transfer is held by an operationally unreachable principal, so the effective-EXECUTE=0 claim for reachable roles is sound.