History and change-eventing for synthetic config entities

The three synthetic market data generation config entities (market_data_generation_config, fx_spot_generation_config, gmm_component) were hand-written across domain/persistence/service/handler and a Qt config UI (list/create/edit/delete + pagination), but WITHOUT the currency-style version history stack and WITHOUT change-eventing. This capture covers adding both, produced via codegen rather than hand-written:

• History: per-entity *_version / *_version_history types, a *_history_protocol (subject synthetic.v1.<plural>.history), a presentation field-mapper (field rendering + diff via ores.diff), *_service::get_*_history wrapping the existing read_all(ctx,id), a handler history method, registrar wiring, and the Qt history dialog + detail-dialog version navigation (first/prev/next/last + revert).
• Eventing: per-entity *_changed_event + event_traits, the postgres NOTIFY -> event-bus -> NATS bridge wiring in the synthetic service application, and the Qt controller subscription that marks list/detail windows stale on change.

History viewing/diff/revert and live staleness are standard across the currency reference pattern, but they are mechanical and voluminous to hand-write (≈25 files/edits per entity). The synthetic config entities are explicitly intended to be regenerated as codegen types once codegen settles, so deferring history + eventing to that codegen pass avoids throwaway hand-written code. The CRUD path is sufficient for end-to-end testing now.

• Story: Synthetic generation configuration and config-driven feeds
• Task: Qt config UI for synthetic market data generation configs