fix(api): scope batch bulk-delete to the calling API key

[diegosouzapw]

Fixes the missing authorization reported privately as GHSA-wvxc-jp3v-5mg5
(CWE-862, High, CVSS 3.1 8.1). Confirmed still present on the release/v3.8.51
tip (d6f3150), not only on the reported v3.8.50.

The defect

DELETE /api/v1/batches/delete-completed accepts any valid ordinary inference
key — including one with scopes: [] — and then called deleteCompletedBatches()
with no ownership predicate:

DELETE FROM batches WHERE status = 'completed';

Every file referenced by those batches was passed through deleteFile(), which
sets content = NULL. One tenant could therefore destroy every other tenant's
completed batches and their stored file contents. No victim batch id, file id or
key id was needed.

Why this shape of fix

Every sibling operation already keeps the boundary — listBatches(apiKeyId?) and
countBatches(apiKeyId?) scope the SQL to api_key_id = ? and fall back to
instance-wide only when the caller is an authenticated dashboard session (which
passes undefined). deleteCompletedBatches was the single operation that
dropped it, so the fix restores the existing convention rather than inventing a
new authorization layer:

• the helper takes an optional apiKeyId and appends AND api_key_id = ? to the
  file collection, the checkpoint delete and the batch delete;
• the route passes scope.apiKeyId || undefined.

Net effect: a dashboard session keeps the instance-wide sweep the UI relies on,
and an API key only ever clears its own batches. The route is the only production
call site (verified by grep across src/, open-sse/, bin/, electron/).

Validation (Hard Rule #18 — TDD)

tests/unit/batches-delete-completed-ownership-wvxc.test.ts pins all three halves
of the contract. On the pre-fix helper the first case fails exactly as the
report describes:

✖ deletes only the caller's completed batches, never another key's
  AssertionError: another key's completed batch must survive — this is the vulnerability
  actual: null  expected: true

After the fix:

Check	Result
new regression guard	3 pass / 0 fail
batch-deletion + batch-deletion-route-logic + batch_api + batches-f9-helpers	60 pass / 0 fail
npm run typecheck:core	clean
eslint + prettier --check on the touched files	clean

Follow-up (not in this PR)

The reporter notes that Threat Model §3.13 documents this path as POST while
the implemented route and the dashboard use DELETE. That is a docs/route naming
mismatch, not an authorization defect, and is left for a separate docs pass.

---

⚠️ base-red inherited: #12732 — release/v3.8.51 is not green. Every failing
check on this PR is inherited, none is a defect of this branch:

• Unit Tests fast-path (1..4/4) — failures are in chatCore, HuggingChat,
  Claude/Responses streaming, catalog build (#9147) and combo.ts. This
  branch touches only src/lib/db/batches.ts and the delete-completed route;
  no batch test fails in any of the four shards.
• Fast Quality Gates / Docs Gates / Merge integrity / API Route Typecheck —
  same shape as the tip, listed in the base-red issue.

The change's own gates are green locally: the new regression guard (3/3), the four
existing batch suites (60/60), typecheck:core, eslint and prettier.

Review batteries (omni-code-review / omni-code-sec)

• fix(api): explicit scope, audit log and atomic sweep for DELETE /v1/batches/delete-completed (omni-code-review battery on #12969) #13262 — code review battery: explicit scope, audit log, atomic sweep (merged 150ca00)
• fix(api): reject revoked, deactivated, banned or expired keys on DELETE /v1/batches/delete-completed (omni-code-sec on #12969) #13297 — security battery: revoked/deactivated/banned/expired keys → 401, buildErrorBody (merged 1eac022)
• fix(db): owner-scoped file half and chunked instance sweep for DELETE /v1/batches/delete-completed (SEC-C/SEC-D, omni-code-sec on #12969) #13374 — security battery follow-up: owner-scoped file half (SEC-C), 200-batch chunked sweep (SEC-D), key-mode parameter-ceiling fix (merged ebd6e19)
• fix(auth): dashboard session requires the authenticated claim — Cursor CLI tokens are not sessions #13375 — SEC-A (forgeable dashboard session, security(auth): any JWT signed with JWT_SECRET is a dashboard session — Cursor CLI key-exchange tokens can forge auth_token #13298) landed directly on release/v3.8.51 (db6feb6)
• Hygiene residuals: chore(auth,db,skills): hygiene follow-ups from the omni-review closeout final reviews (#13375, #13374) #13377