fix(workforce-validation): preserve validity-study case trigger after registry adoption

[seonghobae]

Finding

Exact-child review of #248 at 5d390bc4e86c6db7bcf95a51662cc71500811ad3 found a separate P1 persistence defect after #250. 0002_registry_adoption.sql moves public.validity_study to workforce_validation.validity_study, while the already-deployed public.validate_validity_study_case() trigger function from protected database/migrations/0010_validity_study_case_integrity.sql contains schema-qualified FROM public.validity_study AS study SQL.

ALTER TABLE ... SET SCHEMA preserves the relation OID, trigger attachment and FK objects, but it does not rewrite schema-qualified relation names embedded in PL/pgSQL function source. A valid new validity_study_case_record insert after adoption can therefore fail because the trigger function resolves a relation that no longer exists.

Test-first ordinary repair

• 1644fe53cea801b4a270f38e58dc4a31ece27e3c extends the already-admitted Workforce Validation PostgreSQL contract through protected migrations 0001–0010, builds a real governed selection/evidence/candidate→worker/criterion/study fixture, applies owner adoption, then inserts a valid normalized validity_study_case_record. Against predecessor production, the final insert is causally RED because public.validate_validity_study_case() still reads public.validity_study. The predecessor was superseded immediately, so no hosted RED is claimed.
• b210b6bd201a9b62949da33bc4a9feb92ec6a095 is the minimal production successor. The forward owner-adoption migration uses CREATE OR REPLACE FUNCTION public.validate_validity_study_case() to preserve the existing function identity/signature and governed logic while changing only the study read to workforce_validation.validity_study. The trigger attachment, all non-study evidence reads, relation OID, FKs, RLS, bitemporal guard and runtime-role ACL remain intact.
• Compare 5d390bc... → b210b6b... is two ordinary commits ahead / zero behind and changes only the existing owner PostgreSQL acceptance contract plus the forward adoption migration. Protected global migration history is untouched.

The test now expects four inbound FK dependencies after applying protected migration 0010 (the three foundation links plus normalized validity_study_case_record) and proves the count remains unchanged after the table move.

Exact-head static review

CodeRabbit independently reviewed exact b210b6bd201a9b62949da33bc4a9feb92ec6a095 for #251 and reported no defect in the requested scope. It verified same-relation OID preservation, inbound FK/RLS/bitemporal checks, in-place replacement of the zero-argument trigger function while retaining language/signature/search-path and all non-study evidence reads, continued attachment of validity_study_case_governance_guard, and the post-adoption normalized case insert regression. This is current-head static evidence only; it is not a ruleset-qualifying approval or hosted PostgreSQL GREEN.

Acceptance state

Current #248 exact child head is b210b6bd201a9b62949da33bc4a9feb92ec6a095, still Draft and mechanically mergeable on mutable parent #235. Pull-request workflows do not materialize for this stacked child because the repository-owned Foundation workflow targets PRs into develop; therefore no child-head hosted GREEN, PostgreSQL GREEN, 100% owned statement/branch coverage, terminal security result, or qualifying approval is claimed. Final acceptance belongs after #235 integrates and #248 non-force adopts/retargets to protected develop.

Keep this issue open through #235 protected integration, #248 non-force protected adoption/retarget, fresh exact-head PostgreSQL/coverage/security/review acceptance and normal protected integration. Source repair alone is not a close condition. Do not disable the case-governance trigger, create a compatibility copy/view in public, edit protected migration history, copy mutable parent source, weaken gates, self-approve, or use routine administrator bypass.