fix(api): sanitize /v1/batches create error body (Hard Rule #12)

[xiechimon]

What

POST /api/v1/batches now routes its catch-block error message through sanitizeErrorMessage() before it reaches the client, instead of forwarding the raw error.message.

In my own words: a DB-layer failure during batch create could ship file paths, SQL fragments or internal identifiers to the caller verbatim; this puts the response through the same shared sanitizer every other /v1 route already uses, and the 400 shape stays exactly as before.

Why

Closes #14089. Hard Rule #12 (AGENTS.md): every HTTP / SSE / executor error response must go through buildErrorBody() or sanitizeErrorMessage() from open-sse/utils/error.ts. This route's catch block was the one /v1/* spot that skipped it.

The one-line core fix:

message:
  sanitizeErrorMessage(error instanceof Error ? error.message : "Create failed") ||
  "Create failed",

The || "Create failed" keeps the message non-empty when sanitization fully redacts (the sanitizer returns ""/[REDACTED] shapes depending on input), matching the agents/credentials/route.ts pattern. I left the Zod validation.error.message path (line 30) alone on purpose: that is a schema-generated message with no runtime data, and every sibling route (audio/speech, classify, embeddings, images/generations) passes it through unchanged.

Also checked the other handlers in the file per the issue: GET has no catch block and parseBatchListLimit's message is a static string, so the POST catch was the only leak path.

Testing

New tests/unit/14089-batches-route-error-sanitization.test.ts drives the real POST handler with a real API key and a real seeded input file. The harness does not support mock.module() and mock.method cannot redefine the sealed ESM namespace export, so the batch INSERT is made to throw through the repo's own setDbInstance DI seam: a thin wrapper delegates every read (auth lookup, file ownership, validation) to the real adapter and only the INSERT INTO batches statement throws a path-and-stack-laden SQLITE_CANTOPEN.

• Leak test: the 400 body contains neither the DB path, nor the storage.sqlite filename, nor a stack frame (\n at ); type stays invalid_request_error.
• Control test: a clean, non-sensitive message (Batch endpoint is not enabled on this instance) survives sanitization intact, so the fix does not turn every error into [REDACTED].

Red on base: the leak test fails with response leaked the DB path: SQLITE_CANTOPEN: unable to open database file /tmp/.../storage.sqlite; after the fix, 2 pass.

Adjacent regression: all six existing batch test files green (88 pass / 0 fail, incl. the GHSA-2jm2/GHSA-m3hp ownership suite that exercises the same route). npx eslint and npx prettier --check clean on both touched files; npm run typecheck:core exits 0.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[diegosouzapw]

Thanks @xiechimon — merging via the release merge-train. Validated in local merge-train (mt-train10c) on the devbox @ train tip 4d841aa1c740bbaa03868dc0a403c62099a99a42 with the 72 sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 831/831 (0 failing) and vitest 480/482 — the two reds are autoCombo/provider-family-combos.test.ts timing out at 20s, which reproduces on the PURE release tip under the full vitest suite (and is already tracked by the Release-Green issue #13866), so it is inherited, not this batch's. Merged --admin per merge-gates §3/§4/§7.