Task: Map a trade set's archive into the ORE portfolio

The reverse walk exists, and the run path calls it. ores::ore::xml::exporter::export_portfolio takes the export's trades and their instrument batch, rebuilds each instrument by trade id, reverse-maps it through the per-instrument mappers that sit beside the forward ones in ores.ore.core/domain/, and renders the result with save_data(const portfolio&). Export the trades as the ORE portfolio the engine reads connected it to the run.

Two things about it are wrong for a run that fans out over trade sets.

• It consumes the run's single export_portfolio_response, so a run that gathers per set has nothing to hand it.
• It never fails. A trade it cannot reverse-map goes out as its type and envelope alone, and a trade whose type the ORE schema does not name is dropped, so a portfolio can be quietly missing a trade ORE was meant to price.

This task moves the mapper onto a trade set's archive and makes an inexpressible trade stop the step.

• The mapper walks from a stored trade to the ORE portfolio element it describes, for every instrument type the archive can carry.
• The rendered portfolio is what ORE reads at the file its run document names as portfolioFile, and the engine proceeds past "Build Portfolio".
• A trade the mapper cannot express stops the step and names the trade. This is a change of behaviour: the exporter as it stands writes such a trade as its type and envelope alone, and drops one whose type the schema does not name, rather than refusing either.
• The output is one portfolio per trade set, uploaded as a declared artifact the package step can wait on, named by the batch key.

save_data(const portfolio&) exists, the per-instrument reverse mappers exist beside their forward halves, and export_portfolio already dispatches between them. The work is the input and the failure mode, not the walk: read a trade set's archive into the same two things the exporter already takes, and turn its two silent paths into a refusal.

Do not add a second walk. A builder that walks the archive directly against trade_mapper's element constructors would be a second place that knows the same correspondence the mappers already hold, which is the arrangement the existing reverse mappers were written to avoid.

The step must not emit a partial portfolio. ORE treats a portfolio that parses as the truth of what to price, so a trade that cannot be mapped has to stop the run: a silent omission is a report that prices a portfolio nobody asked for.

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.