ores.cpp.nats-event-registrar

Two templates forming the per-entity NATS event-mapping registrar pair. The header declares register_<entity>_event_mapping(); the implementation registers the entity's Postgres NOTIFY channel with postgres_event_source and republishes the resulting event to NATS. Unlike the sibling ores.cpp.nats-sub-registrar facet, this one generates into the .service layer, not .core, because the eventing pipeline types (postgres_event_source, event_bus) live in ores.eventing.core, which no .core component depends on. Consumed by the default (no --address) generation set for every domain_entity.

Projects the entity model onto its live-eventing registration surface: the Postgres LISTEN/NOTIFY channel a row change fires on, and the in-process event_bus subscription that republishes it as a NATS message. It consumes the same domain_entity model the nats-eventing facet does (the {{entity}}_changed_event struct this facet's implementation subscribes to), and derives its Postgres channel name identically to the notify_trigger SQL facet (product_component_entity_plural), so the two sides of the pipeline can never drift out of sync.

Replaces the pattern of hand-wiring one #include + one register_mapping<T>() call + one event_bus.subscribe<T>() lambda per entity directly in each component's application.cpp — a hand-maintained surface that has already caused two missed-wiring regressions (party_type, purpose_type). A small per-component aggregator (not generated — mirrors ores::refdata::core::messaging::registrar) calls each generated per-entity function, so application.cpp collapses to one call.

• ores.cpp.nats-sub-registrar — the request/response counterpart; lives in .core, not .service.
• Codegen template library — the groups overview.
• How do I wire an entity into live NATS eventing? — the operational recipe.