fix(batches): let session auth cancel any batch, not just apiKeyId-null ones

[hartmark]

Problem

POST /api/v1/batches/[id]/cancel rejected the dashboard's own session-authenticated
caller as "Batch not found" (404) for any batch owned by a non-null api_key_id --
which in practice is every batch created through the default env-key. Clicking
Cancel in the dashboard on /dashboard/batch silently did nothing; the batch just
sat there. Confirmed live: two real stuck batches (validating, in_progress)
both have api_key_id: "env-key" and cancelling_at: null, proving every cancel
click against them had been rejected the whole time.

Root cause

The route carried its own inline ownership check:

if (!batch || (batch.apiKeyId !== null && batch.apiKeyId !== apiKeyId)) { ... 404 ... }

This never exempts session auth (apiKeyId === null, the dashboard) from the
mismatch check the moment batch.apiKeyId is non-null. Two sibling
implementations in the same codebase already get this right:

• batches/[id]/route.ts (GET/DELETE) — its own local scopeCheck()
• deleteCompletedBatches() (GHSA-wvxc-jp3v-5mg5) — scope.isSessionAuth ? undefined : scope.apiKeyId

Both treat session auth as the instance-wide operator, able to act on any
record regardless of which API key owns it. cancel/route.ts was the one
endpoint that never got that exemption.

Fix

• Promoted [id]/route.ts's local scopeCheck() to the shared
  _helpers/apiKeyScope.ts (both routes now import the same function instead
  of carrying independent copies of the same logic).
• Switched cancel/route.ts to use !scopeCheck(scope, batch.apiKeyId)
  instead of its buggy inline predicate.

Evidence

• New regression test (tests/unit/batch-cancel-session-auth-scope.test.ts)
  proves session auth can now cancel a batch owned by "env-key", proves a
  foreign API key still cannot cancel someone else's batch, and proves the
  owning API key still can cancel its own -- plus a source-level assertion
  that the old buggy inline check is gone. Confirmed it fails for the
  intended reason against the pre-fix route (old inline check present) and
  passes against the fix.
• Full sibling batch/file/cancel unit suite re-run (70 tests across 6 files,
  including the GHSA-wvxc-jp3v-5mg5 ownership test and the existing "Batch
  Cancel API" test) — all green, no regressions.
• tsc -p tsconfig.typecheck-core.json clean.

[diegosouzapw]

Confirmed and reproduced: the inline ownership check in cancel/route.ts never exempted
session auth from the apiKeyId mismatch, so clicking Cancel in the dashboard 404'd on any
batch owned by a non-null key (i.e. almost every real batch, since they're created via the
default env-key). The fix correctly mirrors the sibling [id]/route.ts's scopeCheck() —
promoted to the shared helper instead of duplicated — and the new regression test (5/5,
verified against the PR head) proves both the fix and that a foreign key still can't touch
someone else's batch. Clean, minimal, ready to merge.

[diegosouzapw]

Thanks for this, @hartmark — the core of it has landed in #13749, with you credited as co-author on the commit.

Some context on why it went in through a different PR. While triaging two private security advisories (GHSA-2jm2-mpx8-6523 and GHSA-m3hp-hq9g-fpmv), we found that null-owner files and batches were readable, downloadable, deletable and cancellable by any API key, and by anonymous callers under the default REQUIRE_API_KEY=false. The fix needed exactly the shared helper you introduced here, so #13749 builds on your structure:

• canAccessOwnedRecord() in _helpers/apiKeyScope.ts — a dashboard session can act on any record (your "session can cancel any batch" behaviour, kept), an API key acts on its own records only, and a null owner is denied to every non-session caller;
• your batch-cancel-session-auth-scope.test.ts is ported as-is.

The one part that could not carry over is keeping null-owner records open. The rationale that those rows predate ownership tracking doesn't hold: api_key_id has existed since the table was created (migration 028), so a null owner is an unattributable write — every dashboard-session upload, and batch output files that inherit it — rather than a legacy row.

Since #13749 covers this PR's behaviour, it can probably be closed; I'm leaving that call to the maintainer.

[hartmark]

Thanks for the context and the credit — closing this in favor of #13749, which is the correct fix. Appreciate the null-owner rationale being corrected too (api_key_id has existed since migration 028, so that's an unattributable-write risk, not a legacy-row exemption).

[tieng1344]

succeeded