Task: Bind a sensitivity configuration to a report definition

A report definition reaches a SensitivityAnalysis document, so that a sensitivity run shifts the factors the report intends and not nothing.

• A report definition binds a configuration of type sensitivity, and the binding is readable by the pre-processing phase.
• The risk report configuration of a sensitivity report sets sensitivityConfigFile and marketConfigFile, and the seeds of every party that runs a sensitivity report set both.
• A run of a sensitivity report names the bound document in its generated ore.xml and the engine reads it.
• The gate that proves a report runs end to end still passes.

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

• Greek ladder reports — the design this task builds.