Task: Bring party under codegen; verify zero-diff regen

Bring party under codegen management so its SQL, C++ domain, messaging, and Qt layers are generated from a single literate source rather than hand-maintained.

• Party has a JSON driver file and is registered under codegen.
• Regeneration of SQL/C++ core/messaging/Qt profiles is zero-diff, or drift is resolved without losing hand-written business logic.

Investigated the onboarding mechanism used for party_type (commit 58cd323ce, unified SQL codegen model via org-file frontmatter

• ./compass.sh codegen entity generate <entity> --profile sql --diff).

Ran a read-only --diff regen against the current, unmodified party.org.

Regen is not safe to apply: party's insert trigger carries substantial hand-written logic with no template facet — auto-generated codename (whimsical name + sequence, dedicated ores_refdata_party_codename_seq), per-party queue provisioning via ores_mq_queues_create_fn (the NATS-era native-RLS queue replacement, not pgmq), and self-referential parent_party_id hierarchy validation. Regen would delete all three and silently flip business_center_code's SQL nullability to match a pre-existing wrong declaration in party.org. Separately, refdata_party_functions_create.sql (the 3 RLS/hierarchy functions) isn't generated by any template at all — bringing party under codegen would not have fixed its security-definer gap regardless, so that fix was decoupled into its own task (Fix security-definer search_path gap) rather than waiting on this one.

The one template-confirmed positive: the table's own insert trigger does correctly emit security definer set search_path = public, pg_temp on regen — confirming the fix is live in the template, just not reachable for the hand-written functions file.

Filed as a backlog capture rather than continuing here: Generalize self-referential hierarchy validation into a codegen facet. This task stays BLOCKED until that facet (and equivalent facets for codename/queue provisioning, if warranted) exist.