Simulated market data: consistent world vs. scenario workspaces

There are two use cases for simulated market data.

1. The consistent world (e.g. ACME): the whole system uses the same simulated market data as a stand-in for real vendor feeds. All of ACME's parties and any other tenant see the same world, and users must not override the sim data.
2. Alternative scenarios: individual users create artificial data, manually or by automated means, to test something. This needs permission control and a way to lock the live workspace as ground truth. It requires workspace-scoped feeds, which do not exist yet.

The ACME fit-for-purpose review (F15) found that only the first office's synthetic feeds tick: the feed controller keys feeds by source_name service-wide, and every office's configs share the theme's source names. Deciding the strategy resolved the F15 design question: per-office producers would give offices different worlds, which contradicts the consistent-world use case. The decision (2026-08-12) is per-party consumption of a system-party-owned config: the theme publishes once to the system party; each party consumes the shared stream via per-party feed bindings bound to the Live workspace, and materializes its own per-party series. Scenario data lands later with the workspaces feature.

• simulated-market-data-strategy.allium — the strategy spec
• Task: Fix: only the first party's synthetic feeds tick (per-party consumption) — F15 implementation
• Task: Update Market Data Architecture with the simulated-data-generation strategy

• Market Data Architecture