Persist inspector summaries for completed runs in controller storage

[emmepra]

Problem / Opportunity

Completed runs currently expose run metadata after the per-run stack is stopped, but the run-level inspector summary remains tied to the live environment stack. Once the stack is torn down, attempts to inspect a finished run can fail with connection errors even though the run itself completed successfully.

This makes completed runs less queryable than they should be and creates a race between terminalization and downstream analysis/export.

Desired Outcome

A completed or stopped run should always retain a durable inspector summary through the controller API, without depending on the continued availability of the run frontend/backend containers.

Proposed Direction

• Capture the environment inspector summary before terminal stop/deletion paths tear down the run stack.
• Persist that summary in controller-owned run storage.
• Expose a controller route that serves live data while a run is active and cached data after completion.
• Allow repair/recovery for older completed runs that lack a cached summary.

Scope

• In scope: summary-level run state such as post list, scores, vote counts, exposure counts, and interaction count.
• Out of scope: full raw environment interaction history export.

Acceptance Criteria

• GET /runs/{run_id}/inspector/summary returns a valid payload for running runs.
• GET /runs/{run_id}/inspector/summary still returns a valid payload after the run stack has been stopped.
• Export/reporting flows no longer depend on direct scraping of the per-run frontend host port for summary-level state.
• Older terminal runs can be repaired or backfilled without changing the original run result.

Context

• Source: private MIND study runs surfaced a consistent post-completion race where frontend_url was no longer reachable by export time.
• Related: controller run terminalization, per-run stack stop/delete, run exporter logic.