Task: Name a feed by its oresmd URI

An FX feed names the datum it simulates by its ORE key (fx_spot_generation_config.ore_key, e.g. FX/RATE/EUR/USD). The feed turns that key into an oresmd URI at run time (fx_spot_feed.cpp) and the market data ingest turns it back (tick_plan.cpp). ORE keys are an import format, not our identity: the feed should hold the oresmd URI (or the series identity the resolver takes), the web screen should show and pick it as the identity, and the ORE key should be derived for export only. This also lets the feed screen read the feed's stored ticks through the series reads (get_series_slice, get_series_evolution), which take the oresmd identity.

• fx_spot_generation_config holds the oresmd identity in place of ore_key; a migration converts every existing row and every seeded dataset.
• The synthetic feed, the vintage lookup and the market data ingest read the oresmd identity, with no ORE key round trip.
• The FX feed screen shows and edits the identity, and derives it from base and quote as it derives the ORE key today.
• The Qt market simulator reads the same identity.
• The IR curve feed is checked for the same problem and either fixed here or given its own task.

(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.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

• A related capture in the inbox: A feed binding's existence claim is keyed on the ORE key alone. The binding is the feed's consumer side and keys on the same ORE key, so work the two together.
• The FX feed screen and its standard are in place (PR of Build the FX price feed screen); the screen derives the ORE key from the pair in completeFeed and shows it on Details, which this task replaces with the oresmd identity.
• The Ticks tab reads the BFF's tick buffer until the feed holds its series identity; with it, the tab can read the stored observations.

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

Done by the story Name every synthetic feed by its oresmd reference, in PR 3152. The FX feed table holds oresmd_uri in place of ore_key. No migration was written: the data is test data and the database is recreated. The republish subject still uses the ORE key; the task Name the republish subject by the oresmd URI tracks it.