model_work_started forces strict public-eval diagnostics on a sandbox exit that did no model work #320

A sandbox that exits before producing any model accounting is currently reported as a diagnostics validation failure, which hides the real fault and defeats the CI soft-fail policy.

Mechanism

When model_work_started === true, the collector requires PUBLIC_EVAL_DIAGNOSTICS_FILE to be present in the selected evidence. A sandbox that dies mid-run never writes it, so the collector raises public-eval-diagnostics-invalid and the pair is classified permanent-operational-failure.

But the same run reports:

"usage": null,
"counts": { "succeeded": 0, "failed": 0, "remaining": 0 },
"exit_category": "sandbox-exited"

No usage was ever recorded and no node ever transitioned, so model_work_started: true is not supported by any other field in the record. The strict-diagnostics requirement is being applied to a run that demonstrably did no model work.

Corroborating inconsistency

The two summaries of the same run disagree about this exact flag (see #322): status.json reports model_work_generations: 0, unknown_model_work_generations: 1 while recovery-lifecycle.json reports 1 and 0.

Proposal

Require the diagnostics file only when model work is corroborated — non-null usage, or a non-zero node count, or a recorded invocation — rather than on the model_work_started flag alone. A sandbox-exited with null usage should surface as a sandbox failure with its own diagnostic code.

Acceptance criteria

• A zero-work sandbox exit is classified by its exit cause, not as public-eval-diagnostics-invalid.
• model_work_started is derived from, or validated against, corroborating evidence.
• Regression covering the usage: null + all-zero-counts + model_work_started: true shape.

Related: PR #165, #307.