[liuedcson]

Problem

Turn changes, delivery versions and per-turn undo all keyed "did this call change a file" off isError. A call can fail after its write landed — a cancelled then_run keeps the receipt, a result-preparation failure keeps the details — so its patch was dropped:

• the turn's change card and the tool row omitted a file that was really changed;
• delivery cards rebuilt the wrong version of that file;
• undo either reported a turn without changes or reverted the other files and silently left this one behind, while telling the model the turn was reverted.

The record itself is intact in the session JSONL; only the readers skipped it.

Refs #337.

Change

Read the change record instead of the call status: a result with a patch, or with the reason it recorded none (untracked), describes what the call left in the file whatever its isError is. A call that failed before writing records neither, so it stays out of both the changes and the skipped list.

• apps/web/client/src/state/session.ts: fileChange no longer drops every failed result (live rows and history).
• apps/web/src/turn-changes.ts: one recordsAppliedChange predicate used by turnChanges (cards, undo, conflict checks) and replayFile (per-turn versions).
• apps/web/AGENTS.md: state the invariant, so it is not "cleaned up" later.

Rows still read as failed; only the change they applied is kept.

Validation

• apps/web: pnpm exec tsx --tsconfig ../../tsconfig.json --test test/turn-changes.test.ts test/client-live-turn-changes.test.ts — 41 passed.
• pnpm --filter @step-harness/web typecheck and pnpm --filter @step-harness/web test — 864 tests, 0 failed.
• Reverting both predicates makes the new regressions fail (checked).
• Root pnpm run check in the desktop worktree — passed.

Regressions cover: a failed call's change is listed, is not a skip, and undo restores the file; a failed later turn is still what makes an earlier undo a conflict; a failed call that recorded nothing is neither a change nor a skip; a failed call's delivery version stays exact.

Not covered

A call cancelled in the narrow window after the write but before the receipt is built throws a plain error with no details, so nothing is recorded to list. That is a kernel-side ordering issue tracked separately; this change only stops the readers from discarding records that exist.