status rejects orphaned workflow health summary as invalid

Summary

On release/v0.1.0, ultrafuzz status --json rejects the workflow runner's health summary after controller loss even though ultrafuzz inspect --json successfully reads the same linked run and reports the workflow as orphaned.

Minimal reproduction

1. Start a normal run against any generic external Solidity target.

2. Let the workflow reach a durable stopped/orphaned state after controller loss.

3. Run:

   ultrafuzz status <run-id> --project <generic-project> --json
   

Observed:

{
  "schema_version": "ultrafuzz.cli.result.v1",
  "command": "status",
  "ok": false,
  "diagnostics": [
    {
      "code": "WORKFLOW_STATUS_INVALID",
      "message": "workflow runner returned an invalid status summary",
      "severity": "error",
      "source": "workflow"
    }
  ],
  "data": null
}

Control: ultrafuzz inspect <run-id> --project <generic-project> --json succeeds and reports product status failed and workflow status orphaned.

Expected

status should accept the runner's orphaned/stopped health shape and emit a valid concise health result, or map it to a documented terminal/stalled verdict. A stopped controller should not make the read-only status surface unparsable.

Scope

This reproduction contains only UltraFuzz-owned lifecycle/status behavior and a generic external Solidity target. No target identity, source, paths, prompt, model, business logic, or findings are involved.

Start by comparing how ultrafuzz status --json validates the workflow summary with how ultrafuzz inspect --json reads the same orphaned run. Reproduce the stopped-controller case using the commands and generic external Solidity target described above. Done means status accepts the orphaned/stopped shape and emits a valid concise health result or documented terminal/stalled verdict.