Task: Implement classified entities in batches

Every entity the audit/classification task classified as badge or image either has that rendering wired and regenerated, or has an explicit, documented reason it doesn't (e.g. too many distinct values for a badge to be useful). Worked through in the audit's batches, not all 120 entities in one pass – each batch should be its own, independently reviewable unit of work.

• Every 'ready-to-annotate' badge entry from the audit gets badge_key added to its model and is regenerated.
• Every 'ready-to-annotate' image entry gets its image/flag wiring added and is regenerated.
• Every 'needs new data' entry gets its badge_definition/badge_mapping rows or image assets authored first, following the established colour-semantic convention (grey=disabled/no, green=good, red=bad, yellow=warning) where applicable.
• Any audit entry deliberately skipped has a one-line reason recorded in this task's Result.
• Each batch is its own commit (not a separate PR – explicit instruction to minimise PR count, all batches land in the same PR as the audit/classification analysis); zero diff on entities not touched by that batch; build clean; existing badge/image-related tests still pass after each batch.

Picked up Batch 1. Checking the DB directly showed only 3 of the audit's 11 listed entities (calendar_type, currency_market_tier, monetary_nature) actually have code_domain=/=badge_definition=/ =badge_mapping rows today; the other 8 need that data authored first (same as Batch 2) – scoped this pass down to the 3 genuinely ready ones and corrected the audit task's Batch 1 description.

Self-badging pattern (per precedent book_status, task 5BAE2E27): each of the 3 entities' own code column gets is_badge: true=/=badge_key: <itself> in its "Columns (Qt model)" table. Consumer wiring: calendar.org's calendar_type field and currency.org's monetary_nature=/=market_tier fields get their badge_key cell set to point at the corresponding domain (currency.org already had this from earlier session work; calendar.org didn't even have a badge_key column in its Detail fields table header, so that column was added).

Regenerating calendar's Qt facet exposed unrelated drift: a "Browse Holidays" toolbar action had been hand-added directly to the generated CalendarDetailDialog=/=CalendarController files in a past commit, never modelled in calendar.org, and codegen had no paste seam to declare a custom dialog signal or relay it through the controller – regenerating would have silently deleted a working feature. Root-caused and fixed properly rather than working around it:

• Added two new paste seams to the shared ores.cpp.qt templates: one in the detail dialog's signals: block (EC19A4EE-363D-4D41-A33A-D5F85A139C80), one at the end of a new wireDetailDialogCommon() controller helper (DF72DFCF-FD65-4FE5-98BA-CB8168CE0FDF). Documented both in paste_blocks_in_codegen and the ores.cpp.qt meta-model.
• wireDetailDialogCommon() is itself new: extracted the cache-wiring/status/error-connect boilerplate that was duplicated identically across all four detail-dialog construction sites (add/edit/history-version/revert) into one generated helper, so future custom-connect seams (like the one above) only need pasting once instead of four times, and the four sites can't drift from each other. Verified equivalent behaviour (two of the four sites moved from lambda-wrapped emit self->statusMessage(...) to a direct signal-to-signal connect, which Qt treats identically).
• Modelled "Browse Holidays" properly in calendar.org using the new seams instead of leaving it as hand-edited generated code.
• Regenerated calendar_type, currency_market_tier, monetary_nature, calendar, currency via compass codegen entity generate <entity> --address ores.cpp.qt, diffing each first – every diff was exactly the expected badge_key/refactor change, no unrelated drift once the seam fix was in place.
• Fixed two call sites in RefdataPlugin.cpp (MonetaryNatureController, CurrencyMarketTierController) that needed the new badgeCache_ constructor parameter wired from ctx_.badge_cache.
• Not regenerated: the ~100+ other entities with detail dialogs now differ mechanically from the refactored template (still using the old duplicated-per-site pattern) – functionally fine, but a future --diff on any of them will show this mechanical change until they're next touched. Not done here to keep this PR's diff scoped; flagged as optional follow-up cleanup, not a defect.

Build clean (ores.qt.exe, ores.refdata.core.lib); ctest -R "refdata|badge" 4/4 passed.

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.

Batch 1 shipped (PR #1784): all 11 refdata entities (calendar_type, currency_market_tier, monetary_nature, book_purpose_type, business_unit_type, contact_type, ledger_feed_type, leg_type, purpose_type, rounding_type, tenor_anchor) self-badged, with the first 3's consumers (calendar, currency) wired too. The other 8 needed new code_domain=/=badge_definition=/=badge_mapping data authored first (46 values, colour-mapped per ux_language.org's RAG/gray rules) – authored in both the runtime seed and its artefact-catalogue mirror. Regenerated, built, tested throughout.

Batch 2 shipped as the trading slice. The cross-component rollout (feature/badge-batch2-cross-component) decomposed at close: the other components' content is superseded on main or deleted surface, leaving trading as the substantive remainder. party_role_type and trade_type were migrated to the full entity shape (primary key folded into Columns, Table display section) and regenerated – generators now use tenant-scoped generation (generation_keys::tenant_id, thread-safe counter) and emit version = 0 per the current codegen template; the generated table, eventing, messaging, presentation, repository, and service files absent on main were ported. Their generator tests were updated to the current codegen's version = 0 convention – the same stale-expectation fix already applied to the refdata generators (main's trading generators predate the template change and were never regenerated).

Batch 3 (plain-text documentation) is tracked as capture Batch 3 of the badge/image/plain-text rendering rollout.

Side effect, fixed during batch 1: a standing codegen gap – there was no way to add a custom signal to a generated Qt detail dialog (or relay it through its controller) without hand-editing generated code, and the four per-window call sites that wire a detail dialog's caches were duplicated verbatim. Both fixed with two new paste seams and a shared wireDetailDialogCommon() helper in the ores.cpp.qt templates – see Plan for detail. Only the 5 touched entities were regenerated against the refactored templates; the rest of the codebase's detail dialogs still use the old (functionally equivalent) generated pattern until next touched.