Task: Unify synthetic config/binding topology: single cross-asset-class query with a real kind discriminator

Synthetic config/binding is siloed per asset class, with no unified topology query. Surfaced while scoping SyntheticBindingDialog's need to bind both FX spot and IR curve synthetic feeds:

• Each asset class has its own message type pair (get_fx_spot_generation_configs_request/response, get_ir_curve_generation_configs_request/response, and more to come as new asset classes are added).
• Each asset class has its own domain config shape – FX's ore_key is a stored field; IR curve configs don't have one, so the dialog has to compute it client-side by mirroring service-layer logic that isn't linkable from Qt.
• Any consumer needing "all synthetic configs regardless of kind" must know the full asset-class list ahead of time, fire one request per kind, wait for all of them, and manually merge into a client-side union type (BindableConfig{kind, ore_key, source_name}), hand-tagging each with a hardcoded "FX"/"IR" literal since nothing in the wire protocol carries that. This pattern repeats for every future asset class: N request types, N response types, N merge blocks, N hardcoded kind tags, scattered across every UI surface needing a cross-asset-class view.
• A related, deeper instance of the same gap: feed_binding (the table that turns a bound config into persisted market_observations) has no kind/product-type field at all – just ore_key and source_name. Once IR curve configs can be bound through the same table FX already used, any downstream consumer fetching "all feed bindings" (e.g. FxSpotGridWindow) has no way to filter by kind and renders IR bindings as if they were FX pairs. That symptom is tracked separately as its own follow-up (filter feed bindings by product kind), but it is really a symptom of the same root design gap: nothing in this part of the system treats "asset class" as a first-class, queryable dimension – it's implicit in which request type you happened to call.

Proposed direction: replace the per-asset-class request fan-out with a single "what is the current top-level synthetic configuration for this environment/tenant" query, returning all asset classes' configs together with an explicit kind discriminator – so adding a new asset class doesn't require every cross-cutting consumer (binding dialogs, grids, CRM screens, …) to learn a new message type and add another merge branch; kind becomes real, typed data carried on the wire and persisted (on feed_binding too), not something the client infers or hand-labels; and the "renders everything as FX" class of bug becomes structurally hard to introduce, because kind is always available to filter on.

Scope note: this is bigger than the IR-curve-binding task or its FX Spot follow-up – it's a message/API design question that likely touches the synthetic service's request/response protocols, feed_binding's schema, and every consumer currently doing manual per-kind fan-out. Scoped as its own investigation/story-sized task rather than folded into either already-filed follow-up.

• A single cross-asset-class query/message pair replaces the per-asset-class request fan-out (get_fx_spot_generation_configs_*, get_ir_curve_generation_configs_*, …) for consumers that need "all synthetic configs for this tenant/environment".
• The response carries an explicit, typed kind discriminator per config – not something the client infers or hand-labels.
• feed_binding carries a persisted kind/product-type field, so consumers fetching all bindings can filter by kind instead of assuming a single asset class.
• SyntheticBindingDialog and FxSpotGridWindow (or their successors) are migrated to the unified query/kind field, removing their client-side merge/hand-tagging logic.
• Adding a third asset class to this model requires no new message type and no new per-consumer merge branch, demonstrated by the design covering at least one hypothetical additional asset class.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.