[Fix] apply_diff auto-approves edits outside the workspace - #2343

Conflict resolution keeps both sides of the apply_diff work instead of dropping
either one:

- main's 1b9cb7d ([Fix] apply_diff auto-approves edits outside the workspace,
  Zoo-Code-Org#2343) is kept in full: isOutsideWorkspace is computed in execute and in
  handlePartial and carried in both approval payloads.
- this branch's failure-reporting work is kept in full: formatFailedParts and
  truncate, the detailed-failure budgets, the stat-around-read observation
  authorization, and the guarded-save approval plumbing (approvedCanonicalTarget
  plus the isOutsideWorkspace argument to saveDirectly and saveChanges).
- git's auto-merge emitted the isOutsideWorkspace declaration twice in execute
  (main's bare line plus this branch's documented line, textually identical, same
  scope) and the file would not parse. The duplicate line is removed and the
  documented one kept; the merged file typechecks clean and its specs load.
- applyDiffTool.outsideWorkspace.spec.ts: the fs/promises double exposes realpath
  as a named export as well as on the default object (the shape
  writeToFileTool.spec.ts and editTool.spec.ts use), because the merged tool
  canonicalizes an outside-workspace approval target through guardedWrite, which
  reaches realpath through a namespace import. Without it canonicalizeForApproval
  threw the guard's "Path could not be resolved" refusal, the tool catch routed
  it to handleError, and askApproval was never reached - that was the cause of the
  five red rows, measured, not assumed. Setup only: no assertion was changed,
  moved or deleted. The stat double added for the read-around authorization is
  load-bearing the same way (dropping it re-reds nine rows).
- guardedWrite.spec.ts: the Task double exposes abort as a getter over an
  abortState holder, because main's Task.ts:3587 exposes abort as an accessor;
  the two mid-flight abort flips drive abortState.abort instead of assigning a
  read-only property (TS2540 at :1218 and :1234). Same shape as the fws/u6 and
  fws/u8 branches, so the three units carry one fix.

Measured on this tree with pinned node v22.23.4: vitest core/tools/__tests__ +
core/task/__tests__ + core/task-persistence/__tests__ -> 81 files, 1671 passed,
5 skipped, exit 0; tsc --noEmit -p tsconfig.json -> exit 0, 0 error lines;
eslint --max-warnings=0 on the five merge-touched files -> exit 0 each; prettier
--check -> exit 0; eslint --prune-suppressions (whole src) -> exit 0 with no
semantic change, file restored. Negative controls on the same tree: dropping the
payload flag at both payload sites -> 9 failed | 2 passed (11); skipping the
stat-around-read block -> 1 failed | 56 passed (57); dropping the spec's stat
double -> 9 failed | 2 passed (11); restoring the writable abort field -> tsc
exit 2 with the two TS2540 rows.

…about the hardened guarded write

applyDiffTool.outsideWorkspace.spec.ts arrived with 1b9cb7d (Zoo-Code-Org#2343). Its doubles describe the tool as
it behaved before the guarded-write series hardened apply_diff: an fs/promises double with readFile only,
and a diffViewProvider.open() stubbed as a no-op over originalContent: "". The hardened tool stats around
its own read to capture the version token its guarded publish consumes, and fails closed when open()'s
re-read disagrees with that read. So on any branch that carries the hardened tool, execute() never reaches
askApproval: 9 of the 11 rows fail ('expect(askApproval).toHaveBeenCalledTimes(1)' got 0 calls at spec:135,
':197', ':219') even though nothing about the outside-workspace decision changed.

This touches the test file only; no production line changes.
- fs double gets a stat (:26-31): rejecting, which is the case the tool already tolerates by publishing
  unguarded-by-token (the token is kept only when the file did not change between stat and read).
- open() double records its re-read (:111-117): the real open() re-reads the file and keeps that text as the
  save baseline, which is exactly what the staleness check compares against.

Measured (Windows box, pinned node 22.23.4, root-junction bins):
- this tip: outsideWorkspace 11 passed (11), exit 0; tsc --noEmit 0 errors; eslint --max-warnings=0 0
  messages on the file; prettier --check clean; eslint-suppressions.json untouched (delta empty).
- without the hunks, in the 1408-head + main merge tree (tree 73632a8): 9 failed | 2 passed (11), the
  same 9 rows CI's platform-unit-test (windows-latest) reported in run 42565686409 job 128991579779.
- with the stat hunk only: 7 failed | 4 passed. With both hunks: 11 passed (11), and that merged tree
  passes its whole core lane: 201 files, 4363 passed | 9 skipped (4372), exit 0.
- negative control: main tip e487cd7 alone, that spec 11 passed (11) - the file is fine today; it is only
  unreadable against the hardened tool.

Zoo-Code-Org#1408 (feat/guarded-write-wiring-s4b) is the pull request waiting on this: its windows arm is red against a
file that is not on its branch, and its owner deliberately did not carry this file across, because both
sides adding it with different content is an add/add conflict in the merge tree.

Brings in Zoo-Code-Org#2343 (apply_diff auto-approves edits outside the workspace), Zoo-Code-Org#2283 (task
abort/abortReason run-state latches), Zoo-Code-Org#2324 (Turbo cache input contracts), Zoo-Code-Org#2327
(CSS transitions for visual themes) and Zoo-Code-Org#2277 (aimock 1.47.0), so the required arms
judge this branch against the content they actually check out.

The merge is textually clean and ApplyDiffTool.ts lands as main's content with this
branch's hunks applied on top, which is the composition the arms need. The only
reconciliation needed was in main's new applyDiffTool.outsideWorkspace.spec.ts: its
diff-view double stubbed open() as a no-op and left originalContent at "", which is
the fixture shape applyDiffTool.failureReporting.spec.ts warns about. The stale-base
guard added on this branch reads open()'s re-read as the save baseline, so that
double reported a stale base that never happened and execute returned before asking
for approval - nine failures in CI's windows lane. The double now re-reads through
the same fs mock and provides the stat the tool takes around its read; main's
c assertions and expectations are untouched.

Brings 1404 up to the content the required arms actually check out: the 20 non-merge main
commits between its merge base 3ee042d and main tip e487cd7, including Zoo-Code-Org#2283 (task
abort/abortReason run-state latches, which turn Task.abort and Task.abortReason into getter-only
accessors), the settings round-trip unit e943530, Zoo-Code-Org#2343, Zoo-Code-Org#2324, Zoo-Code-Org#2327 and Zoo-Code-Org#2277. 29 of this
branch's 43 delta files were also edited on main and every one of them auto-merged.

Nothing had to be reconciled, and that was measured rather than assumed: tsc --noEmit over the
merged tree exits 0 with zero error rows once @roo-code/types resolves to the merged packages/types
(it reported 25 perWriteCheckpoints rows while resolving to a sibling checkout's stale types, which
is a resolution artifact, not a defect in this tree). The accessor hazard that class of merge usually
produces is absent here: this branch's Task.ts never assigns this.abort or this.abortReason (its three
mentions are comparisons), and the five spec-side writes all land on object-literal doubles that
declare abort as a mutable property or on a local { abort: boolean } alias. Control: injecting
'this.abort = true' inside the getter body produces exactly one row, TS2540 Cannot assign to 'abort'
because it is a read-only property, and removing it returns the program to exit 0, so the check would
have caught the hazard if the merge had created it.

…about the hardened guarded write (Zoo-Code-Org#2372)

applyDiffTool.outsideWorkspace.spec.ts arrived with 1b9cb7d (Zoo-Code-Org#2343). Its doubles describe the tool as
it behaved before the guarded-write series hardened apply_diff: an fs/promises double with readFile only,
and a diffViewProvider.open() stubbed as a no-op over originalContent: "". The hardened tool stats around
its own read to capture the version token its guarded publish consumes, and fails closed when open()'s
re-read disagrees with that read. So on any branch that carries the hardened tool, execute() never reaches
askApproval: 9 of the 11 rows fail ('expect(askApproval).toHaveBeenCalledTimes(1)' got 0 calls at spec:135,
':197', ':219') even though nothing about the outside-workspace decision changed.

This touches the test file only; no production line changes.
- fs double gets a stat (:26-31): rejecting, which is the case the tool already tolerates by publishing
  unguarded-by-token (the token is kept only when the file did not change between stat and read).
- open() double records its re-read (:111-117): the real open() re-reads the file and keeps that text as the
  save baseline, which is exactly what the staleness check compares against.

Measured (Windows box, pinned node 22.23.4, root-junction bins):
- this tip: outsideWorkspace 11 passed (11), exit 0; tsc --noEmit 0 errors; eslint --max-warnings=0 0
  messages on the file; prettier --check clean; eslint-suppressions.json untouched (delta empty).
- without the hunks, in the 1408-head + main merge tree (tree 73632a8): 9 failed | 2 passed (11), the
  same 9 rows CI's platform-unit-test (windows-latest) reported in run 42565686409 job 128991579779.
- with the stat hunk only: 7 failed | 4 passed. With both hunks: 11 passed (11), and that merged tree
  passes its whole core lane: 201 files, 4363 passed | 9 skipped (4372), exit 0.
- negative control: main tip e487cd7 alone, that spec 11 passed (11) - the file is fine today; it is only
  unreadable against the hardened tool.

Zoo-Code-Org#1408 (feat/guarded-write-wiring-s4b) is the pull request waiting on this: its windows arm is red against a
file that is not on its branch, and its owner deliberately did not carry this file across, because both
sides adding it with different content is an add/add conflict in the merge tree.