Task: Ask a run's health from the shell

The shell asks a run's health and reads the same answer the web does.

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

The shell asks a run's health, and the answer is the service's own.

report_operations get-run-health <report_instance_id> is a generated verb. The operation is declared in ores.reporting.operations.org with subject reporting.v1.ops.get_run_health, and the protocol, the shell command unit, its tests and the shell recipe are generated from it.

The service side is hand-written but asks nothing new. It calls report_instance_service::get_report_instance_health, the read the web already makes, with the one id, and projects the row onto the one-run answer. A read that answers no row is a run that does not exist or is not the session's, and the answer is missing rather than an empty word a caller would read as a state.

Proven from the shell against a triggered package run. Instance c0922bbf: state_name completed, health completed clean. An id that does not exist answers missing with "The report instance does not exist."