fix(workforce-validation): validate exact UUID payload before sentinel comparison

[seonghobae]

Finding

#243 removes retained UUID object aliases by reducing accepted UUID authority to immutable integer payloads, but exact outer uuid.UUID type is still not sufficient evidence that its internal int slot is a built-in integer. Python permits object.__setattr__(exact_uuid, "int", attacker_object). On #243 head 65052598187e8b7b177f58e65f83d004dbfa8f83, _require_operational_uuid(...) evaluated value.int in (0, _MAX_UUID_INT) before proving type(value.int) is int; an executable object stored in an exact UUID could therefore run caller-defined __eq__ during validation. _store_operational_uuid(...) also read .int again after validation.

This is distinct from #243 retained-alias mutation. #244 concerns a forged/corrupted exact UUID entering the boundary with executable or non-integer internal storage before the immutable snapshot exists.

Test-first ordinary repair

Canonical #235 advanced through three ordinary ahead-only commits:

• 23bdae68d23b5d50673184ab0a2dccd0dad3d355: adds test_uuid_payload_integrity.py. The regression constructs an exact UUID, replaces its internal int slot with _ExecutableUUIDPayload, whose __eq__ raises if executed, and requires ValidationPrincipal(...) to fail closed with ValueError without invoking that equality hook. The test-only head was superseded before hosted execution, so no hosted RED is claimed.
• 7f7617b4225d96aed0f6d522c25302228b8a6bde: production root fix. _require_operational_uuid(...) first proves exact UUID outer type, reads .int exactly once into local identity, requires type(identity) is int, then performs zero/max/range validation and returns the validated integer. _store_operational_uuid(...) now stores that returned scalar directly rather than re-reading .int.
• 7c71f81c63ff87d6524fd565b3b5ce444905ca2e: README makes the exact-UUID-internal-payload boundary code-current.

The repair preserves #243 immutable integer UUID storage/pre-port target binding, exact UUID subtype rejection, zero/max sentinel rejection, #239 constructor-bypass validation, #240 inert read-port capability validation, #241 immutable minimized output, #242 authorized-only issuance, Keyverse ordering, owner-schema bootstrap, and Foundation coverage gates.

Exact-head review

CodeRabbit independently reviewed exact 7c71f81c63ff87d6524fd565b3b5ce444905ca2e against protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f and reported no blocking defect in the requested #244 scope. It confirmed that the UUID payload is captured once, exact built-in int is established before sentinel/range comparison, the executable payload regression fails closed without calling attacker equality behavior, and #243 plus #239–#242 ordering remain intact. This is exact-head independent static review evidence only; it is not a ruleset-qualifying APPROVED review.

Acceptance state

Current #235 head is 7c71f81c63ff87d6524fd565b3b5ce444905ca2e, open · Draft · mechanically mergeable over protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f. Exact-head Foundation 33962944744 / Repository quality 101297910519 is still queued before checkout with steps=[], ubuntu-24.04, and runner_id=0. CodeQL PR 33962944749, SAST Semgrep 33962944737, Security Scan 33962944753, Noema 33962943840, OpenCode 33962943857, Strix 33962943816, and required PR review/merge scheduler 33962943848 are also non-terminal. No hosted GREEN, 100% owned statement/branch coverage, executed PostgreSQL GREEN, terminal security completion, or qualifying approval is claimed.

Keep this issue open through exact-head hosted/security acceptance, qualifying ordinary review, and normal protected integration. Do not weaken exact UUID/sentinel validation, Keyverse authorization ordering, owner-schema bootstrap, Foundation coverage gates, or cross-context SQL boundaries.