Task: Fix refdata entity model drift: update to latest format and regenerate

While verifying zero-diff on Split every codegen template org into commented literate blocks's pilot batch, regenerating country (unmodified templates, git checkout HEAD confirmed the drift is pre-existing) showed 6 files diverged from what current templates produce: country_repository.cpp, country_service.cpp, ClientCountryModel.cpp, CountryDetailDialog.cpp, CountryMdiWindow.cpp, country_protocol.hpp, country_handler.hpp. This is a real risk for the literate-splitting task: every split must be verified against a clean baseline, or a pre-existing drift could be silently attributed to (or mask) a splitting mistake.

Sweep every refdata domain_entity and junction model (77 entities): regenerate each, and where the org model itself is using an outdated convention (rather than the templates having simply moved on), update the model to the current format before regenerating. Commit the resulting clean, drift-free tree. This blocks the literate-templates task, which resumes once refdata regenerates byte-identical (or with only intentionally-committed changes) across the board.

• Every refdata domain_entity and junction model is regenerated via compass codegen entity generate and shows zero diff on a second regen (idempotent).
• Any model found using an outdated format/convention is updated to the current one before regenerating.
• compass build and ctest pass after the regenerated files are committed.
• No entity outside refdata is touched.

(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.)

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.

Regenerated every refdata domain_entity (68 of them) against current codegen templates; junction entities (calendar_date and 8 siblings) were left out of scope – 8 of the 9 error with "junction has no ** Qt drawer", which would mean authoring substantial new Qt/messaging scaffolding rather than fixing drift. Filed as a follow-up.

Along the way, found and fixed real bugs beyond simple regeneration:

• cpp_history_field_mapper template didn't handle date/timestamp natural keys (surfaced by calendar_exception).
• 9 entities (calendar_type + 8 convention entities) had a pre-existing broken build on this branch from earlier sessions: stale protocol field names in their Qt layer, and calendar_type's stale umbrella messaging/protocol.hpp include.
• counterparty and party were both missing :flag_icon_column:, which would have silently dropped their logo/flag-upload feature on regeneration.
• party's SQL is explicitly flagged hand-maintained (BLOCKED codegen task, no paste-block coverage for its touch-version function, codename generation, per-party queue provisioning) – caught this only after a full regen of it broke schema creation; reverted that commit. The revert took the :flag_icon_column: property with it and the described Qt-only re-run didn't actually happen until PR review caught it (see Review #1) – reapplied in f7773b2f9.
• 4 synthetic generators (business_unit, business_unit_type, party_id_scheme, business_centre) fabricated soft-FK values (business centre / coding scheme codes) that don't exist in a freshly-recreated default database – some using values only seeded by optional artefact datasets, one missing :no_generator_suffix: on a natural key. Fixed all 4; swept every other refdata generator for the same anti-pattern, no further occurrences found.

compass build and full rat (test suite) both green after every commit in the final state.

Follow-up needed: author Qt drawers for the 8 refdata junctions still on stale templates, then regenerate them.