feat(board-worker): persist executor failure diagnostics (close the investigation gap)

[ProtocolWarden]

Summary

Answers "why isn't the controller investigating?". board_unblock now requeues failed tasks, but execution failures were diagnostically opaque: dispatch ran the executor with capture_output=True yet discarded proc.stdout/stderr on every failure path, team_executor persists no run artifacts, and the task recorded only a summary (N of N stages failed). A recurring failure (e.g. #264, 4/4 stages) could not be root-caused — the controller could only blind-requeue, and the evidence was thrown away.

Fix

persist_failure_diagnostics() writes the executor's stdout/stderr + result.json to a durable logs/local/failures/<role>-<short_id>.log and appends a [diagnostics: <path>] pointer + tail to result['failure_reason'], which flows into the task comment and fleet log. Wired into dispatch's failure branch; also captures the retry proc output (previously discarded too). Best-effort — never crashes dispatch.

Verification

5 new tests; 240 board_worker tests pass; ruff/ty clean; pre-push audit 0 findings; dispatch kept at 499 lines (C29). Deployed directly to the live fleet so the next execution failure is captured.

[ProtocolWarden]

Resolved: superseded by new push — re-review resumed

Self-review concerns — auto-fixing (up to 6 attempts; re-queued if still unresolved):

Critical concern: Variable proc scope. The diff shows proc being captured only in the retry section (line 279), but persist_failure_diagnostics(proc, ...) is called at line 335 which appears to be outside the retry block. This would cause NameError if the initial dispatch fails without triggering a retry, unless proc is also captured from the initial dispatch (not shown in diff). Verify that: (1) the initial dispatch result also captures proc, or (2) the control flow ensures persist_failure_diagnostics is only called when proc is in scope.

Otherwise: Implementation is well-designed (bounded output, best-effort error handling, thorough tests). Function logic is correct, tests are comprehensive (5 tests covering main cases and edge cases), and integration points are reasonable. Code quality is high.