Story: Improve badge colour scheme support

Analysis (task 2, done) found the badge system the story assumed didn't exist already does: a database-driven badge_severity=/=code_domain=/=badge_definition=/=badge_mapping catalogue in ores.dq, a client-side BadgeCache, and codegen support (badge_key column annotation) that generates the delegate wiring automatically. Booleans already badge correctly via the same (code_domain, entity_code) mapping is_sweepable uses — no new storage design is needed.

Delivered: the badge_mapping browser UI (the highest-leverage single piece of work, since it makes badge source self-use, coverage gaps, and colour-semantic misuse all reviewable instead of grep-only), and migrating badge_definition=/=badge_severity=/ =code_domain onto standard codegen and DQ publishing.

Closed at Sprint 23's end, narrowed to what shipped. The remaining scope split into two Sprint 24 stories by kind of work: concrete UI fixes vs. an open-ended coverage audit — see Badge colour scheme: visual polish and self-badging fixes and Classify and roll out badge/image/plain-text rendering across domain entities.

• A badge_mapping browser exists (System > Configuration), grouped/ filterable by code_domain, with a colour swatch per mapped badge.
• badge_definition=/=badge_severity=/=code_domain run on the standard generated core/service/handler stack and publish through the standard DQ bundle mechanism, replacing the prior hand-written equivalents.
• No regression to any currently-working badge rendering (existing entities' generated files stay zero-diff except where this story deliberately changes them).

• Closed at Sprint 23's end with acceptance narrowed to what shipped, rather than left open indefinitely. The remaining BACKLOG tasks split into two Sprint 24 stories by kind of work, not lumped into one: concrete, scoped UI fixes (palette swatch, self-badging) vs. an open-ended coverage audit across 108 domain_entity models — the latter is a distinct initiative, not a small tail.
• Do not move badge colour onto each "table enum type"'s own row (the story's original hypothesis). The current normalised (code_domain, entity_code) -> badge_definition mapping's whole value is letting many entity types share one badge definition (active=/=inactive alone is reused by book_status, regulatory_book_type, is_sweepable, tenant_status, workspace_status, …); per-table colour columns would fragment that reuse and lose the single catalogue the admin UI manages. Keep the architecture, close the visibility/adoption/self-use gaps instead.
• badge_mapping browser first, ahead of the audit/annotation work, because it's the tool that makes the audit and the colour-semantic review possible in the first place, not just a nice-to-have alongside them.
• Wt is explicitly out of scope for this story's tasks (user instruction), but the data/protocol layer was checked for architectural soundness first: badge_definition already carries both raw hex colours and an unused css_class Wt hint, so a future Wt client isn't blocked by anything here — only the fallback-colour hardcoding needed fixing to keep that promise, which this story does as part of the palette-swatch task.

• Wt-side badge rendering (account_list_widget.cpp still hardcodes Bootstrap CSS classes directly) — real, confirmed gap, but explicit user instruction to ignore it for this story.
• Moving badge colour storage onto individual lookup tables — see Decisions above.