Task: Export the market data a trade set requires

marketdata.v1.ops.export_market_data_to_storage takes no set and no date. Its own documentation states the stance: an ORE market file "is a snapshot of everything a run needs, not a slice of one series, and an export that could name a subset would produce a file that does not reproduce anything". That was true of a whole-tenant run. A run that gathers per trade set needs the export narrowed to the requirements that set resolves and read at the set's as-of, so two runs of one set on different dates read different rows.

• The request names a trade set, and the as-of comes from the set.
• The export writes only the series that set's resolution requires.
• The rows are read as of the set's date, not as of now.
• A requirement that no series answers fails the step and names the missing data, because ORE cannot price a curve whose quotes are quietly absent.
• The market and fixings bodies remain what ORE parses, as they are today.

The serializer already exists and is proven: ore_export_service::write_all walks the series, observations and fixings and renders the files ORE reads. What changes is the selection it walks and the date it reads at, so this task is mostly about the resolution task's output reaching it.

The documented stance above has to be reversed deliberately rather than quietly: the comment argues that a subset does not reproduce anything, and the answer is that the resolution is what makes a subset reproducible — the set is derived from the trade set's own members at a stated date, not chosen by a caller who might choose badly. When the stance changes, that reasoning belongs in the same comment.

Fixings are read the same way and stay a separate file, because the engine reads them from one of its own.

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.