fix(people): exact-gate Position parent UUID evidence before equality

[seonghobae]

Finding

Canonical People mutation PR #64 previously exact-gated persisted UUID/datetime/text/Decimal evidence in the generic PostgreSQL projections, but PostgresPeopleMutationPort.create_position(...) still compared the DB-returned organization_unit_id and job_profile_id with command UUIDs before establishing that either returned parent identity was an exact built-in operational UUID.

A custom DB row factory could therefore return a UUID subtype whose __eq__/__ne__ executed during parent-identity comparison. That violated the same inert durable-evidence boundary enforced by #221–#224.

Test-first repair

• Test-only ordinary successor 11c30cd5d0514caf4096578a8337042e6a583e6e adds a focused public-port regression for both Organization and Job parent positions. The UUID subtype raises from equality/inequality hooks, so predecessor control flow reaches a real RED failure before PeopleMutationIntegrityError.
• Production ordinary successor/current fix(people): protect governed mutation runtime types #64 head 46884c24886654edb86a2233e690fd2cb4473c3a invokes the existing exact _is_operational_uuid(...) gate for both returned parent identities before either equality comparison.
• Direct production compare is one commit and one file (postgres_mutations.py), +3/-1. SQL/schema/transaction semantics, authorization, audit, idempotency, and exact Psycopg UUID compatibility are unchanged.
• No force-push, destructive rebase, source copy, self-approval, or gate weakening occurred.

Current acceptance state

Test-only workflow runs were cancelled after the production successor arrived, so hosted RED is not claimed. Exact-head Foundation CI 33928065506 / Repository quality 101200790759 remains queued before checkout at 46884c24886654edb86a2233e690fd2cb4473c3a with steps=[], ubuntu-24.04, and no runner assigned. Exact-head SAST Semgrep 33928065420, CodeQL PR 33928065609, and Security Scan 33928065430 are also queued. Hosted GREEN, PostgreSQL acceptance, and 100% statement/branch coverage are not claimed.

Fresh CodeRabbit review explicitly evaluated exact 46884c24886654edb86a2233e690fd2cb4473c3a against protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f, reported no defect, and confirmed both _is_operational_uuid(...) checks execute before their corresponding parent-identity equality comparisons. This is independent static review evidence, not a ruleset APPROVED review. All submitted formal #64 reviews remain COMMENTED; existing inline threads are resolved.

Keep this issue open until exact-head hosted acceptance and ordinary protected integration are complete. #163/#165 remain consumers of normally integrated protected owner truth only.