fix(core): address review feedback for tool execution status (#8180)

- Gate cancel message on executionThrew so the model sees 'User
  cancelled tool execution.' when execute() rejected under abort,
  reserving 'already completed' wording for post-processing cancels
- Move StructuredToolError into tool-error.ts to break the
  tool-error ↔ priorReadEnforcement module cycle
- Revert unrelated Prettier reformat in generate-notices.js

packages/core/src/core/coreToolScheduler.ts

@@ -5565,8 +5565,9 @@ export class CoreToolScheduler {
 
       if (aborted) {
         // PostToolUseFailure Hook (user interrupt)
-        let cancelMessage =
-          'The tool had already completed; its output was discarded.';
+        let cancelMessage = executionThrew
+          ? 'User cancelled tool execution.'
+          : 'The tool had already completed; its output was discarded.';
         let failureHookArtifacts: ToolArtifact[] | undefined;
         if (hooksEnabled && messageBus) {
           const failureHookResult = await this.withHookSpan(
@@ -5646,7 +5647,9 @@ export class CoreToolScheduler {
             'cancelled',
             createCancelledResponse(
               scheduledCall.request,
-              'The tool had already completed; its output was discarded.',
+              executionThrew
+                ? 'User cancelled tool execution.'
+                : 'The tool had already completed; its output was discarded.',
               executionStatus,
               failureHookArtifacts,
             ),

packages/core/src/tools/priorReadEnforcement.ts

@@ -9,34 +9,7 @@ import type { FileReadCache } from '../services/fileReadCache.js';
 import { ToolErrorType } from './tool-error.js';
 import { ToolNames } from './tool-names.js';
 
-/**
- * Error thrown by `getConfirmationDetails()` when it needs to surface
- * a structured `ToolErrorType` to the scheduler instead of letting
- * the throw collapse into a generic `UNHANDLED_EXCEPTION`. Originally
- * introduced for prior-read enforcement (hence the file location)
- * but now also carries other content-derived `calculateEdit` errors
- * — `EDIT_NO_OCCURRENCE_FOUND`, `EDIT_EXPECTED_OCCURRENCE_MISMATCH`,
- * `EDIT_NO_CHANGE`, `ATTEMPT_TO_CREATE_EXISTING_FILE` — through the
- * confirmation path so they keep their proper error code instead of
- * being reported as "unhandled exception".
- *
- * Caught by `coreToolScheduler` via the `errorType` instance field.
- *
- * Naming note: kept generic (`StructuredToolError`) rather than
- * `PriorReadEnforcementError` so the name matches the broader set of
- * `ToolErrorType` values it actually carries — an oncall engineer
- * seeing this in a log paired with `edit_no_occurrence_found` should
- * not have to wonder what prior-read has to do with it.
- */
-export class StructuredToolError extends Error {
-  override readonly name = 'StructuredToolError';
-  constructor(
-    message: string,
-    readonly errorType: ToolErrorType,
-  ) {
-    super(message);
-  }
-}
+export { StructuredToolError } from './tool-error.js';
 
 /**
  * Result of checking whether a tool that mutates an existing file is

packages/core/src/tools/tool-error.ts

@@ -141,4 +141,31 @@ export enum ToolErrorType {
   SEND_MESSAGE_NOT_RUNNING = 'send_message_not_running',
 }
 
-export { StructuredToolError } from './priorReadEnforcement.js';
+/**
+ * Error thrown by `getConfirmationDetails()` when it needs to surface
+ * a structured `ToolErrorType` to the scheduler instead of letting
+ * the throw collapse into a generic `UNHANDLED_EXCEPTION`. Originally
+ * introduced for prior-read enforcement
+ * but now also carries other content-derived `calculateEdit` errors
+ * — `EDIT_NO_OCCURRENCE_FOUND`, `EDIT_EXPECTED_OCCURRENCE_MISMATCH`,
+ * `EDIT_NO_CHANGE`, `ATTEMPT_TO_CREATE_EXISTING_FILE` — through the
+ * confirmation path so they keep their proper error code instead of
+ * being reported as "unhandled exception".
+ *
+ * Caught by `coreToolScheduler` via the `errorType` instance field.
+ *
+ * Naming note: kept generic (`StructuredToolError`) rather than
+ * `PriorReadEnforcementError` so the name matches the broader set of
+ * `ToolErrorType` values it actually carries — an oncall engineer
+ * seeing this in a log paired with `edit_no_occurrence_found` should
+ * not have to wonder what prior-read has to do with it.
+ */
+export class StructuredToolError extends Error {
+  override readonly name = 'StructuredToolError';
+  constructor(
+    message: string,
+    readonly errorType: ToolErrorType,
+  ) {
+    super(message);
+  }
+}