Generate messaging registrars via codegen

• Pure boilerplate. Each message = a near-identical subscribe+lambda; a component has dozens. Nothing here is a real decision — it is mechanical subject↔handler-method wiring derivable from the model.
• Manual and error-prone. Easy to mistype a subject, double-subscribe, forget a message, or attach the wrong handler method; no compile-time guard.
• Inconsistent signatures across the 20. register_handlers variously takes (nats, ctx, verifier), (nats, verifier), (nats, ctx, optional<verifier>), (nats, shared_ptr<controller>); some are static, some not; verifier is sometimes optional, sometimes by value. No single contract.
• "Grouping" is cosmetic. Per-entity separation is comment banners inside one growing function — the registrar is itself a blob.
• Not codegen-driven → drift. Adding/changing an entity means hand-editing the shared registrar, the exact coupling the SQL/C++/Qt codegen removed elsewhere. The queue name, subject list, and handler methods already live in the entity's protocol + handler codegen models, so the registrar restates information the generator already has.

1. Standardise the contract first: one register_handlers signature for all components — static std::vector<subscription> register_handlers(nats&, database::context, std::optional<jwt_authenticator> verifier) — so the generated body is uniform. Components that genuinely differ (e.g. controller-based feeds, the http discovery-only registrar) stay hand-written and are explicitly excluded.
2. Add a registrar codegen archetype/facet. The entity protocol model already declares each message type (and thus its nats_subject) and the handler model declares the delegate method per message. Generate, per component, a registrar that loops the component's entities: instantiate each <entity>_handler and emit the subscribe+delegate line for each message→method pair. This is the messaging analogue of the per-entity route aggregator proposed for HTTP.
3. Drive grouping from the model, not banners — the generated file is ordered by entity because it iterates the entity list, so structure is real.
4. Verify byte-identical regeneration against the current hand-written registrars for one component (e.g. refdata or scheduler) before rolling out, then delete the hand-written versions.

Outcome: adding an entity wires its NATS surface automatically (codegen run, no shared-file edit), and the 20 registrars collapse to one template + per-entity model data.