Task: Hand each configuration to its owner by id at an as-of

The run document's configuration documents are pulled synchronously inside prepare_ore_package: export_run calls each owner's document operation in turn, with the run token, and waits. One call answers for every configuration, so nothing is an artifact, nothing can be produced in parallel, and the package step cannot start until the slowest owner has answered.

Ask each owner for one configuration by its id and an as-of, have the owner write it to storage, and let the mapping happen afterwards.

• Each configuration is requested on its own, naming its configuration id and the as-of date.
• The owner writes the document to storage as an artifact the run declares, so the package step waits on artifacts rather than on a blocking call.
• The run document itself is one of these artifacts, not a special case.
• A configuration whose document is missing fails the run and names the configuration.

The precedent is already in the tree and this task follows it rather than inventing one: for the configuration documents, the owners return neutral documents and ores.ore.core renders the ORE XML through curve_configuration_mapper::reverse, todays_market_mapper::reverse, pricing_engine_mapper::reverse and conventions_mapper::reverse. The owners do not know the ORE schema, and that stays true — only the transport changes.

So the shape is: reporting asks the owner for one configuration by id at an as-of; the owner writes the neutral document to the run's storage prefix; the run declares it as an artifact; and ores.ore consumes it when it renders the package. The id is the configuration row the definition already binds, and today's export_run walk is the list of owners this splits into.

The one question the task must answer is what carries the document: the neutral domain type serialised to storage, or a new message type per configuration kind. The first keeps one transport shape for every kind, which is what makes the package step indifferent to which owner produced what.

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.