Write-mode task jobs report status "completed" even when zero workspace writes landed

When a task --write dispatch fails to land any workspace writes (e.g. the Windows sandbox denies apply_patch and all fallback writes — see openai/codex #30712/#31220/#32314), the companion still records the job as status: "completed" with touchedFiles: []. The orchestrating agent only learns of the loss from the model's prose.

Observed in production (companion 1.0.4, Windows 11, codex-cli 0.144.4): a write-mode rescue job ran ~6 minutes, every write path was denied by the sandbox, zero files landed — and the job record read status: "completed", so the coordinator dispatched follow-up work on the assumption the edits existed.

Suggested behavior: detect zero-write completion mechanically and surface the job as failed/degraded so callers see the loss without parsing prose. Note that touchedFiles alone is insufficient as a signal — it only tracks apply_patch file-change events, so shell-based writes (the common Windows fallback while the sandbox split-root issue stands) need a working-tree fingerprint comparison to avoid false positives.

Happy to submit a PR — implementation plus tests are ready (working-tree fingerprint before the turn; job marked failed with result.degraded: "zero-writes" and a DEGRADED banner when a write turn ends with no apply_patch changes and an unchanged fingerprint; shell-only writes and already-dirty-file edits covered; non-git workspaces skip detection).

Start at the task --write dispatch and job-status handling, then trace how touchedFiles and the working-tree state are recorded. Add coverage for zero writes, shell-only writes, already-dirty files, and non-git workspaces; done means failed or degraded status with result.degraded: "zero-writes" and a DEGRADED banner when appropriate.