A2: add sanitized error classification fields (additive)

[MrTravisB]

Summary

Second PR in Stack A. Stacked on #389 (A1).

Additive change - no existing field is removed, no caller breaks. Adds
structured classification fields to the error response so dashboards and
programmatic retry logic can reason about failures without parsing
message strings.

What's added

• error.class - error constructor name (e.g. "TypeError", "SyntaxError")
• error.reason - coarse-grained enum, safe for metric labels: INVALID_REQUEST,
  PROVIDER_UNAUTHORIZED, NAVIGATION_TIMEOUT, BROWSER_DISCONNECTED,
  MAX_ITERATIONS, MAX_ERRORS, TIMEOUT, INTERNAL_ERROR
• error.recoverable - boolean derived from error instanceof RecoverableError
• error.phase - which pipeline phase produced the error: "setup" or "execution"

What stays (unchanged for consumers)

• error.message - human-readable string, still present
• error.timestamp - ISO timestamp, still present
• error.code - fine-grained semantic code, still present
• error.taskId - from A1, still present

The data-sensitivity invariant

error.message must never contain raw error.message of a thrown value
(agent errors can quote task text, URL selectors derived from page content,
or extracted values). The new code enforces this two ways:

1. Validation / setup errors use hardcoded string literals at the callsite
   ("Task is required", "AI provider is not configured.", etc.). Server-controlled
   by construction.
2. Task execution errors go through errorResponseFromError, which sets
   message from a fixed REASON_HINTS map keyed by the reason enum. No code
   path reads error.message of the thrown value into the response.

A canary test throws new Error("DO NOT LOG THIS SENTINEL") and asserts the
sentinel never appears in the serialized response.

Before / after

Before (old code, still passes through tabs-api to customers):

{
  "success": false,
  "error": {
    "message": "Task is required",
    "code": "MISSING_TASK",
    "timestamp": "2026-04-21T12:00:00.000Z"
  }
}

After (additive, still readable by old consumers):

{
  "success": false,
  "error": {
    "message": "Task is required",
    "code": "MISSING_TASK",
    "timestamp": "2026-04-21T12:00:00.000Z",
    "class": "Error",
    "reason": "INVALID_REQUEST",
    "recoverable": false,
    "phase": "setup",
    "taskId": "..."
  }
}

Minor security improvements (bundled)

Dropped two WS error paths that previously echoed client-provided strings
back in the message:

• UNKNOWN_EVENT no longer quotes msg.event
• UNKNOWN_REQUEST_ID no longer quotes the requestId
• INVALID_SEARCH_PROVIDER no longer echoes the user-provided value

Changes

• packages/server/src/taskRunner.ts - new ErrorReason / ErrorPhase
  types, extended ErrorResponse, new createErrorResponse (object-param
  signature) and errorResponseFromError helpers, classifyError mapper,
  REASON_HINTS map. errorToString removed (no callers left).
• packages/server/src/routes/pilo.ts - validation errors use new shape via
  validateTaskRequest; setup-error path uses createErrorResponse with
  explicit reason: INVALID_REQUEST; task-execution path uses
  errorResponseFromError.
• packages/server/src/routes/piloWs.ts - all createErrorResponse callsites
  migrated; task-execution error uses errorResponseFromError; dropped
  client-provided values from error messages.
• Tests: taskRunner.test.ts / pilo.test.ts / piloWs.test.ts updated to
  assert new fields alongside existing message/timestamp/code. Added
  canary tests that assert no sentinel string ever appears in the serialized
  response regardless of what the thrown value's .message is.

Test plan

• pnpm --filter pilo-server run test (78 passing)
• pnpm --filter pilo-core run test (658 passing)
• pnpm --filter pilo-cli run test (221 passing)
• pnpm run typecheck green
• pnpm run format:check green
• Canary: thrown Error("DO NOT LOG THIS SENTINEL") never appears in response JSON
• Manual: curl -X POST /pilo/run -d '{}' returns 400 with both the old
  message: "Task is required" AND the new reason: "INVALID_REQUEST",
  phase: "setup", class: "Error", recoverable: false

Notes

• Base: travis/pilo-task-id (stacks on A1: propagate taskId through pilo server and core #389)
• Revised from an earlier internal design that dropped message/timestamp
  outright - that removed visibility for consumers with no safety benefit
  (both fields were already server-controlled). This revision keeps both,
  enforces server-control at the helper layer, and adds classification
  fields alongside.
• A3 next: redacting OTel recordSanitizedException wrapper so span
  payloads also stop leaking raw error messages.