Task: Add the run configuration and address phase results by role

Give the report definition a run configuration, carry it into the workflow start message, and make the workflow build the phase list that configuration names. At the same time replace the positional results[N] access with a lookup by phase role, because a second chain shifts every index after the phase it adds.

• A definition's run configuration selects the phases that run, and a run is reproducible from the database alone.
• No step consumer reads an earlier result by index; a missing result fails loudly instead of yielding an empty field.
• A definition whose configuration executes every phase still runs the existing chain unchanged.

Four parts, in the order each depends on the one before it.

1. Results addressed by role. A step result becomes a named pair rather than a bare JSON string: workflow_step_result carries the step's name and its response, workflow_step_results is the list of them, and find_step_result answers the payload the named step produced. The engine builds that list from every forwarded step, an empty answer included, because the list it built before skipped empty answers and so its positions were not step indices. A builder that cannot find or cannot read what it consumes throws; the engine catches that at dispatch and starts compensation, so a missing result fails the run instead of publishing a command with an empty field.
2. The run configuration. The definition table gains pre_processing, prepared_input_key and post_processing, so the choice of phase is definition state and a run is reproducible from the database alone. The trigger validates the codes, refuses a substituting definition that names no archive, and copies the configuration into report_execution_request, the payload the engine stores and hands to build_steps.
3. The chains. One registered definition builds either chain from that payload. execute and execute are the seven steps the definition ran before; substitute replaces the four pre-processing steps with one that resolves the named archive; ignore replaces result collection with one that records the batch and leaves it unread. Submission takes the name of whichever step filled the input role, so no consumer is told which producer ran.
4. The substitutes. Both are reporting operations, and both answer in the result type of the phase they replace. That shared answer is what makes them indistinguishable to the step after them, and it is why the substitute requests name an existing result struct rather than a type of their own.

Deliberately not done here, and owned elsewhere in the story: the instance does not record which phases were substituted (the substituted-pipeline task adds it), retrieval is not yet separated from result collection, and resolving the prepared archive does not read it, so nothing checks that it is a valid engine input or digests it.

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 report definition now says how much of the pipeline a run executes, and the workflow builds the chain that configuration names.

The run configuration is three columns on ores_reporting_report_definitions_tbl — pre_processing, prepared_input_key and post_processing — so it is definition state and a run is reproducible from the database with no operator present. The trigger validates the codes, refuses a substituting definition that names no archive, and copies the configuration into the workflow start payload, which the engine rebuilds the chain from on every dispatch and on recovery.

Step results are addressed by the name of the step that produced them. The engine now carries an entry for every forwarded step rather than only the ones that answered, because the old list's positions were not step indices and one silent step shifted every later result. A builder that cannot find or read what it consumes throws, and the engine turns that into compensation, so a missing result fails the run instead of publishing a command with an empty field. Five build_command definitions moved to the signature; the provisioning workflow, the only other consumer that read a result by position, reads save_account by name.

One registered definition builds both chains. execute and execute are the seven steps the definition ran before; substitute replaces the four pre-processing steps with resolve_prepared_input; ignore replaces result collection with ignore_compute_results. Both substitutes are reporting operations and both answer in the result type of the phase they replace, which is what makes them indistinguishable to the step after them, and submission is given the name of whichever step filled the input role, so neither phase knows about the other.

Deferred on purpose, and owned by other tasks in the story: the instance does not record which phases were substituted, retrieval is not yet separated from result collection, and resolving a prepared archive does not read it, so nothing checks that it is a valid engine input or digests it.

The branch also carries one unrelated fix. The clean-http change stopped env_init.py generating ORES_HTTP_SERVER_JWT_SECRET without recording a new .env format version, so no checkout was ever told to regenerate and every one of them kept a line that make_mapper("HTTP_SERVER") maps onto an option no parser registers — which stops ores.http.server at its next start. Version 26 records the removal, and this checkout's .env was regenerated and the gateway restarted to confirm.

Verified locally, since CI runs no full build: the whole tree builds, the reporting, shell-reporting, workflow core and api, refdata api and reporting service suites all pass, compass lint and the structure-note link check are clean, the schema validator reports no warnings, and the reporting component has no codegen drift.