Story: Classify FK-like/lookup entities and decide badge vs image vs plain-text rendering policy

Every FK-like/lookup/code entity in the system currently gets an ad hoc rendering treatment decided per-entity as it's built: badge_definition renders as a colour swatch, currencies render as flags, and everything else renders as plain text — with no documented policy for which treatment a given entity should get. This surfaced concretely while fixing badge severities: is a severity itself a badge? What about code_domain? There's no criterion to answer that.

This story inventories every FK-like/code/lookup entity, classifies each one against a small set of rendering treatments (colour badge, image/flag, plain text), documents the policy that drives the classification, and updates codegen so future entities pick up the right treatment automatically instead of by convention-following.

• An inventory exists of every FK-like/code/lookup entity in the system (reference-data codes, DQ badge-adjacent entities, currencies, and any others of the same shape).
• Each entity is classified into one of: colour badge, image/flag, or plain text/neither — with the reasoning documented, not just the verdict.
• A written policy/decision doc captures the classification criteria so future entities can be assigned a treatment without re-litigating the question each time.
• Codegen is updated so an entity's rendering treatment is a declarative choice in its model, driving the generated Qt list/detail views automatically.
• Existing entities affected by a policy change are regenerated to match (e.g. any entity currently mis-classified, such as badge severities if the decision is that severities should be badges).

• Redesigning the colour palette or flag/image asset pipeline themselves — this story is about classification and codegen wiring, not visual design of the treatments.