Reconstruct Orrery graphs from existing build output artifacts #1170

Summary

Add a command, probably a CLI, that takes the output artifacts of an existing build and reconstructs the most complete Orrery graph those artifacts support. Builds that ran before automatic graph export (#1150 / #1151) can then be viewed in the runs application without being rerun.

Motivation

UK builds now export graph.orrery.json and a publication inventory (orrery.upload.json) automatically from evidence recorded during the run. Earlier runs, and runs whose inputs are no longer available, have no graph artifact, and a fresh build cannot reproduce their execution. Many of those runs still leave substantial evidence on disk or in staged bundles.

Proposed behavior

Given a build output directory, staged bundle or attempt evidence directory, the command should:

1. Discover the evidence present. Candidates include:
   • per-phase run manifests (<phase>.graph.json);
   • evidence-index.json and attempt evidence under .graph-store/uk-*-attempts/;
   • graph.schema.json / execution.evidence.json where present;
   • spine sidecars (*.build.json, spine.graph.json);
   • gate reports, diagnostics, build.json, rowwise_candidate_manifest.json;
   • staging run files (progress.json, events.ndjson);
   • the content store.
2. Build the graph from the richest source available. Use recorded execution evidence where it exists. Otherwise fall back to the declaration for the code revision recorded in the run, and attach whatever receipts, timings, gate results and artifact digests can be bound to individual operations.
3. Mark the provenance of every node and field: recorded, recovered from a receipt or sidecar, or declared only. It must never present inferred or declared-only structure as recorded execution. Operations with no evidence should appear as such, not as completed.
4. Verify artifact digests before linking them. Report missing or mismatched files rather than silently dropping them.
5. Write the same publication layout the build produces: graph.orrery.json, the allowed evidence files and orrery.upload.json. Existing publication and runs-app tooling can then consume it unchanged.
6. Report what was recovered and what was missing in a short summary.

Open questions

• Which historical artifact formats and schema versions should be supported first? Probably the UK dense and national lines.
• How should the declaration be resolved for a run built at an older code revision? Options are the run's recorded code pin, a checked-out revision, or a stored schema.
• Should reconstructed graphs carry an explicit marker that the runs application can display?

Out of scope

Rerunning any part of a build, and changing how new builds record evidence.