Story: Organise feeds by provider and scope

Make a provider a system-level record, give every feed a system or test scope, seed the provider catalogue by provider and kind, and browse feeds through one tree by scope, provider and feed kind.

• A provider is a system-level record with a code, a name, its kind, its logo and its asset classes, seeded with the main vendors and exchanges.
• A feed has a scope: a system feed is owned by the installation under one provider, and a test feed is owned by a tenant or a party.
• System feeds are organised provider, then feed kind, then the folders the provider's data needs.
• Market data has one feed browser: a tree of System feeds by provider and Test feeds with run roll-ups, start and stop at any node, and the kind's list and feed page at its leaves.
• Every path a feed is known by marks it as synthetic.

The remainder is carried in Subscribe tenants to provider feeds and prove the browser at scale.

• Two scopes, one feed shape. A system feed and a test feed are the same record with the same process and the same screens; the scope decides who owns it, who may write it, and who may read it. The FX price feed screen needs no second editor.
• Providers are system data. A provider (Bloomberg, Refinitiv, ICE, CME, LSE, a broker) is reference data of the installation, in the system tenant, as the other shared catalogues are. Its feeds run in the system tenant, once, and publish to the bus once.
• Consumption is a binding, not a copy. A tenant or party that wants a provider's FX spot does not get a copy of the feed; it gets a feed binding onto the provider's source, which the market data ingest already honours: the tick is stored once per enabled binding, under the binding's tenant and party. This is the consistent-world model the bindings were built for, and it is why A feed binding's existence claim is keyed on the ORE key alone and Name a feed by its oresmd URI come first: many parties will bind one source.
• Organised by provider, then kind, then the provider's own folders. The folder hierarchy stays the mechanism, and the system tenant's root is System feeds with one folder per provider. Under a provider, a folder per feed kind (FX spot, IR curves, later surfaces and order books), then what the kind needs, such as a pair group or an exchange segment. A tenant's test feeds keep the party root and its collections.
• One browser, kind screens as leaves. Market data gets a feed browser: a tree on the left (System feeds by provider, Test feeds), the chosen node's feeds on the right through the kind's list, and the kind's feed page when one is opened. The FX price feed list and page become that leaf, and the per-kind cards under Market data become entry points into the tree.
• One way to set up feeds. Feeds come from a synthetic feeds dataset (DQ artefact type synthetic_feeds), published by one function into the party provisioning names; the "theme" was that dataset and is renamed to it. A feed row names its provider, and its source name follows the provider. Until the services read system collections, a provider's feeds are published as a party collection like any other.
• Built for scale from the first screen. Order books and wide provider catalogues mean tens of thousands of feeds. The tree loads one level at a time and asks the server for each node's counts and run roll-up; every list is paged, searched and sorted on the server; start and stop act on a node through the folder cascade the service already has; the running read and the tick buffers are checked at that size. No screen reads all feeds.
• Every path says the feed is synthetic. A simulated Bloomberg feed must never be read as Bloomberg. Every name a feed is known by starts with the synthetic mark: the source name (synthetic.bloomberg.fx.eurusd), the tick subject (synthetic.v1.ops.tick.synthetic.bloomberg.fx.eurusd), the folder path (Synthetic feeds › Bloomberg › FX spot), and the provider as a screen names it (Bloomberg (synthetic)). A real provider connection added later uses its own namespace and cannot collide.
• Source names carry the provider. After the synthetic mark, a system feed's source is qualified by its provider and a test feed's by its party, so two scopes never claim one source.
• A system collection is the system tenant's. It belongs to the system tenant and its system party, the party the super administrator works in, as every other shared catalogue does. The earlier null-tenant reading of system scope could hold no feeds, because a feed must share its collection's tenant.
• One bound provider per pair, for now. The collection's conflict guard stays: one enabled, bound system collection at a time. So the first step creates the providers and binds one of them, chosen arbitrarily, as the authoritative source of a pair such as EUR/USD; the other providers' collections run sandboxed. The second step is a rate blending service that reads the providers' spots and owns the blended EUR/USD itself.

• Does a provider feed's process belong to the installation administrator only, or may a tenant tune a private copy of a provider feed as a test feed?
• Is a tenant's subscription one binding per feed, or one per provider and kind with the feeds under it implied?
• Do order books share the feed record and the process editor, or are they a kind with its own model (levels, depth, events)?

• Real connections to Bloomberg, Refinitiv or an exchange. These are simulated providers.
• Order book feeds themselves; this story makes the organisation and the browser ready for them.
• Entitlements and billing of provider data per tenant.