fix(job-analysis): detach exact UUID payload before canonical evidence comparisons

[seonghobae]

Finding

Fresh review of canonical shared HRIS-kernel owner #63 found the nested exact-UUID payload hazard already repaired in Workforce Validation #244 still present in Job Analysis evidence. At predecessor 510b50b9faa4fae8c3404752e464fd17ba8124ae, job_analysis._validate_uuid(...) proved only type(value) is UUID, then evaluated value.int == 0 / max before proving the retained .int was the exact built-in int, and returned the caller-owned UUID object.

Python permits object.__setattr__(exact_uuid, "int", attacker_object). A forged exact UUID therefore executed attacker equality during sentinel validation, while an otherwise-valid caller UUID remained aliased inside frozen Job Analysis values and could change after construction through the caller-held object.

This is the shared Job Analysis occurrence of the #244 invariant; it does not copy mutable Workforce Validation #235 source.

Test-first / repair progression

• 3bb641bd825e7203c211b3ff47b7f59f7c35a0ca added exact-UUID payload and caller-alias regressions. Hosted runs admitted but were queued before the production repair; no hosted RED is claimed. The vulnerable predecessor behavior was independently reproduced against the exact implementation shape: executable .int.__eq__ ran before rejection and _validate_uuid returned the same caller UUID alias.
• 03ba635e33eba8514f9e99db27661133cf08161a changes _validate_uuid(...) to read .int once, require exact built-in int, enforce 128-bit range before nil/max comparisons, and return UUID(int=identity) as an owned value. Every Job Analysis canonical UUID field stores that detached return rather than merely checking the caller object.
• A broader audit UUID repair was intentionally reverted in ordinary commit 0e5d43288ce1442678c2b00fc0a95adcf164af3c because audit.py is manifest-sealed and must be handled as its own test/reseal slice rather than smuggling an unsealed source change into this acceptance. That occurrence is fix(audit): validate and detach exact UUID payload in canonical envelopes #278.
• 4ab735df1f0a6533694f59f180f8ddabc72fe3f9 scopes the regression to Job Analysis and covers executable non-int payload, lower/upper out-of-range integers, and caller-alias detachment.

Hosted RED -> GREEN

Foundation 34292861193 on exact 4ab735df1f0a6533694f59f180f8ddabc72fe3f9 produced a real RED in Run owned unit and service contracts once: all new UUID regressions passed and HRIS-kernel coverage remained 100%, but the pre-existing test_unresolved_timezone_is_rejected_for_source_snapshot_and_review still expected the superseded resolve to a UTC offset message. The already-adopted timezone hardening correctly rejects the custom tzinfo earlier with must use a standard-library timezone provider; restoring custom callback execution would have weakened the security boundary.

Exact successor 4ad9363af660f137b4c8c575b68113e7883c8129 changes that stale compatibility expectation/name only. Foundation 34293147207 is terminal SUCCESS on that exact head: compile, foundation-pack validation, owned unit/service contracts with 100% statement/branch coverage, isolated PostgreSQL contracts, manifest validation, and read-only validation all pass. SAST/Security/CodeQL and independent review remain separate ordinary merge gates; no predecessor verdict is transferred.

Acceptance

Nil/max sentinels, exact outer UUID type, timezone-provider hardening, canonical Job/FJA/KSAO semantics and PII boundaries remain intact. Keep this issue open through normal protected integration or a verified successor with complete Job Analysis delta/evidence. docs/product-technical-gap-baseline.md remains #100 single-writer; the durable nested-payload/caller-alias invariant has been handed off there without a competing baseline edit.