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

Regenerate party's SQL/C++/messaging/Qt against current codegen templates and diff against the repo; fix templates or repo to eliminate drift.

• Zero-diff regen for party across C++ (repository/service/handler/registrar/protocol) and Qt profiles. DONE.
• Qt layer migrated from ores.qt.party to ores.qt.refdata, RefdataPlugin owns PartyController. DONE.
• Build green for ores.qt.refdata.lib and ores.qt.party.lib. DONE.
• SQL profile regenerated with zero diff. NOT DONE – deliberately excluded; see Result.
• Identifier/contact-information embedded-table editing in the Qt detail dialog. NOT DONE – see Result.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

./compass.sh codegen entity generate party --diff produces a ~4900-line diff, most of it destructive if applied as-is:

• Codename auto-generation (whimsical name + sequence suffix), the backing sequence, its unique partial index, and its uniqueness/regex/length validation have no codegen facet coverage. The template's default, indexes, and extra_checks facets could plausibly cover the index and check-constraint parts, but I could not confirm org_loader.py actually wires those two facets from entity .org models (same class of gap as the counterparty Validations-facet bug found in sprint 22) — needs verification before relying on them.
• The per-party report-event queue provisioning (ores_mq_queues_create_fn call in the insert trigger) is party-only hand-written logic with no facet; would need a paste block (existing d4e8e136-... trigger-body marker, same one counterparty used for its country_code validation).
• The sequence declaration itself (create sequence ... party_codename_seq) has no injection point anywhere in the template — it's top-level DDL, not something that fits inside the trigger-body paste marker. This is genuinely missing codegen-template capability, not just an unfilled facet; landing it needs a new paste-block kind documented in org entity meta model, analogous to the existing "SQL: extra drop statements" kind but for the CREATE TABLE section.
• :generate_touch_function: true is simply missing from party.org's Flags — party_identifier already declares :bump_parent_version: true on the child side, but party never declared the parent-side flag. This part is a one-line, low-risk fix, independent of the above.
• The rest of the diff (repository context ctx parameter modernization, search_path hardening, faker-generator improvements) is expected, wanted drift-correction — safe to apply once the above is resolved.

Regenerated protocol/handler/registrar (same composite_as_of/read_for_cache/ workflow-step paste-block treatment as the SQL side notes below already described), then discovered the regen was coupled to party's repository and service layers too: unlike counterparty's (already modernized in sprint 22), party's repository/service were still on the pre-context ctx-per-call pattern (find_party(uuid), remove_party(uuid), no-arg list_parties()), which the current handler template no longer matches. Regenerated repository and service as well; both were safe (party.org's own custom repository method paste blocks – read_system_party, read_descendants – already declared the new context ctx signature, just never regenerated against it). Found and removed two now-redundant custom-method paste blocks (read_latest_paginated, get_total_party_count) duplicating what the generic :service_pagination: true facet already generates – they caused duplicate-declaration compile errors once regenerated. Fixed my own read_for_cache=/=composite_as_of paste blocks to match the new service signatures (list_parties(offset, limit) instead of no-arg; get_party_at_version(string, version) instead of uuid; log_handler_entry replaced with BOOST_LOG_SEV, matching the modernized handler style).

Regenerated Qt profile and migrated party's Qt layer from ores.qt.party to ores.qt.refdata the same way as counterparty: moved PartyController ownership to RefdataPlugin, deleted the old hand-written ClientPartyModel=/=PartyController=/=PartyDetailOperations=/ =PartyHistoryDialog=/=PartyMdiWindow from ores.qt.party.

SQL profile was not regenerated. Party's codename generation (sequence, unique index, uniqueness/regex validation) still has no facet/paste-block coverage, same finding as before – but per direction, the per-party report_events queue provisioning was not carried forward via a paste block; instead captured to the backlog inbox as Party's per-party report_events pgmq queue looks half-baked / unused since no consumer code anywhere reads from it. Codename generation itself is real, user-visible functionality (rendered in the Qt UI) and still needs proper facet/paste-block treatment before party's SQL can be regenerated – left for a future pass.

ores.qt.refdata.lib and ores.qt.party.lib build clean (-j1); the full ores.qt.exe app link is blocked only by an unrelated, pre-existing ores.qt.marketdata issue from another environment's in-flight work.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.