Task: Name a curve pillar's market series

Implement A pillar names the market series it reads: a curve pillar states the market series its quote comes from, so the bootstrap no longer derives the series from the ORE vocabulary. A person can then read a blueprint's inputs, and a curve can be built from any series the party holds.

The task carries the model change, the reader change, the pillar picker, the seed, the tests, and the recreation of the demonstration tenant.

• ir_curve_bootstrap_pillar carries market_series_id, a soft reference to ores.marketdata.market_series, required on a new row.
• The Add and Edit pillar dialogs offer the party's series through the standard record picker and draw the chosen one by its oresmd URI.
• curve_pillar_reader reads the observations of the named series at the as-of, and derives the datum's term from the pillar's end tenor as it does today.
• The bootstrap's read path calls neither make_pillar_quote_key nor its projections, and curve_republish_service no longer validates an output datum through ore_key_codec::write.
• ir_curve_feed builds the series it publishes as oresmd datums natively. It composes no ORE key.
• series_classifier and its seeded rules are keyed by the oresmd identity, and the ingest paths in feed_ingest_loop and fixing_ingest classify by it. This is the largest unit: the rules are data, and every series a feed creates passes through them.
• oresmd_uri_codec accepts a datum with no ORE spelling.
• ore_key_codec is called only by import_service, ore_export_service and their tests.
• The test suite proves no runtime path outside the ORE XML boundary calls the codec, and a curve builds from a hand-seeded series that no feed publishes.
• The demonstration tenant is recreated and reseeded, and the scenario walks a curve to publication against the named series.

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

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.

A pillar now names the market series it reads.

• ir_curve_bootstrap_pillar carries market_series_id through full codegen.
• The curve reader reads the named series' observation at the as-of and takes the rung whose term the pillar's end tenor resolves to; one series answers a whole ladder and the lineage names it once.
• The read path no longer composes an ORE key: make_pillar_quote_key and pillar_datum_uri are gone, replaced by pillar_quote_datum for the feed.
• The Add and Edit pillar dialogs pick the series with the standard record picker, drawn as its oresmd URI.
• The feed and the reader agree because they build the same datum, not because they share a spelling; the synthetic and marketdata suites prove it.

Evidence: marketdata core 330, service 203, synthetic 94; codegen idempotent over two runs; live: the seeded pillars name the seeded series.

• Bootstrapping a curve: from quotes to a published set — the structure note that orders this cluster, and where to read this page in it.
• The market data path: a public fixing, a curve, a report — the structure note that orders this cluster, and where to read this page in it.