Story: Synthetic data scope and binding: system/tenant/party levels, bound vs sandboxed

Give synthetic market data generation two orthogonal primitives – scope (system/tenant/party) and binding mode (bound/sandboxed) – so a tenant can choose to share one synthetic reality across its parties (ACME's case), and so synthetic data can later be generated for testing (new ORE configs, quant models) without silently overriding real system behaviour.

• market_data_generation_config carries a scope (system/tenant/party) and a binding_mode (bound/sandboxed), each correctly nullable/FK'd per scope level
• Activating a bound config that narrows an already-covered instrument at a wider scope is rejected, requiring explicit supersession – never silent override
• Sandboxed configs generate and publish data end-to-end under a distinct namespace, provably excluded from bound-feed resolution used by real consumers
• ACME's 3 existing party-level configs (UK/US/HK) are consolidated into a single tenant-level bound config; ACME parties share one synthetic reality
• Market Simulator tree filters by viewer scope (own party's configs plus any tenant/system configs visible to them) instead of showing every party's configs unfiltered
• Design doc records the future workspace-scoped binding direction (live workspace = real feeds, user workspaces bind to sandboxed synthetic runs) without implementing it

• Conflict resolution is reject-at-activation, not resolve-at-read (narrowest-scope-wins was considered and rejected: two feeds silently generating for the same instrument risks confusing debugging and wastes compute).
• Sandbox mode ships runnable (generate + publish under a namespace), not merely a schema placeholder – validates the primitive actually works end-to-end, even with no consumer UI yet.
• ACME's three party configs are consolidated in this story, not deferred – otherwise the story ships the primitive but ACME's UX is unchanged.
• scope=/=binding_mode are hand-written C++ enums (following the existing domain::asset_class precedent), not the codegen ores.cpp.enum facet – that facet exists but has no live usage yet in the codebase; introducing its first real usage was out of scope for this task.
• The reject-at-activation conflict check lives in the database as a hand-written insert-trigger paste block (cross-row logic doesn't fit the per-column FK validation mechanism), not in service-layer C++ – keeps the guarantee true regardless of write path (Qt, shell, direct SQL), consistent with how version conflicts and tenant validation already work in this trigger.
• Qt enum columns need a formatter (a small hand-written label function) wired via the Columns table – the generated Qt list-model code's string column type assumes the underlying field actually is a std::string; there is no generated enum-to-QString path yet.
• Sandboxed-feed exclusion from the bound-feed path is enforced two independent ways – a distinct NATS subject namespace and no feed_binding row – rather than relying on just one. Either mechanism alone would be sufficient today, but the redundancy means a bug in one doesn't silently collapse the guarantee.
• Live-testing the primitive (not just unit tests) surfaced a real gap a unit test alone would have missed: the JetStream stream backing synthetic ticks only covers the pre-existing subject pattern, so publishing to a new subject with no matching stream crashes the service. Worth remembering for any future new-subject work in this service: a new producer subject needs its own ensure_stream, not just a passing unit test.
• The conflict-guard trigger from the first task was fixed to no longer block two enabled bound configs at the same party – an established, legitimate, pre-existing pattern (multiple named containers per party, e.g. "Basic"/"Realistic"), broken by the original over-broad guard and only surfaced by actually provisioning ACME rather than by unit/pgTAP tests alone.
• The guard's remaining granularity is per-tenant, not per-theme: promoting one container to tenant scope requires retiring every other enabled bound party-scope container in that tenant, not just duplicates of the same theme. Consolidating ACME meant retiring all six pre-existing party-level containers (two themes x three parties), not just the two directly-duplicated ones – a real, known consequence of the guard having no per-instrument visibility (see the trigger's own comment). Live-testing against real ACME data is what surfaced this; it would not have been obvious from the original design discussion alone.
• RLS read-widening (added for the container in the first task) had to be extended one layer down to fx_spot_generation_config and gmm_component – promoting the container's scope alone does not make its sub-configs visible to other parties; their own party_id-based RLS needed the identical read-widen/write-stays- strict treatment, joined through to the parent container's scope.
• No new tooling/API was built to make consolidation itself repeatable – executed as documented, reproducible SQL against a live database, going through the same versioned-insert path (and hence the same conflict guard) the app's own writes use. Automating this into provisioning, or exposing it as a "supersede and consolidate" action, is future work.
• Found and fixed four pre-existing bugs while getting ACME provisioning to actually run (two schema-drift issues in ores.marketdata unrelated to this story, one regression in this story's own first task): each was small, contained, and directly blocking, so fixed inline rather than deferred as separate captures.
• Shell command tokens resolve by exact match only (UUID, folder name, ore key, source_name) – no substring/partial matching, which was considered and rejected as a recipe for confusion; ambiguous tokens list every candidate (folder path / source_name) so the user can pick the full token. Multi-word names use the REPL quoting idiom ("synthetic list folders --name \"2026 Realistic\""), consistent with --tenant-name "Acme Corporation" elsewhere in the shell.
• Folders are the one market-simulator entity without a stable machine-readable identifier (no code, unlike tenant code / config name / feed ore_key). A stored code column was considered and rejected: the codebase already derives machine tokens from display names (source_name is the config-name slug plus the pair, built in publish_from_dq), and folder names are themselves derived from DQ dataset names at publish – not user-renamed – so a stored code would have no rename-stability consumer, would drift from the name, and would force schema regeneration across every layer. Follow-up task folder-code-identifier is re-scoped to derive the identifier at resolve time: each folder's codename is its slug (lower(replace(name, ' ', '')), mirroring source_name), and folders resolve as uuid -> exact name -> codename path. Codename paths are standard, filesystem-style paths walked component-by- component from the tree root (2026realistic/fx, synthetic/2026realistic/fx), so same-named folders under different collections are addressed by path; a bare codename (fx) matches at any depth and reports ambiguous, listing each candidate's codename path. A ' > '-joined display-path token form ("2026 Realistic > FX") was considered during implementation and rejected as messy and untypable.

• Any UI/UX for a consumer (ORE run, model test) to select and attach to a specific sandboxed config/run.
• Workspace-scoped bindings – ores.workspace is not touched by this story; only documented as a future direction.
• System-level (cross-tenant) configs being exercised end-to-end by any real scenario – the scope value is supported by the data model and resolution logic, but no current tenant needs it activated.