[diegosouzapw]

Fixes two privately reported advisories with one root cause: GHSA-2jm2-mpx8-6523 and
GHSA-m3hp-hq9g-fpmv. Subsumes #13683 (credit to @hartmark in the commit trailer).

Root cause

getApiKeyRequestScope() never rejects. Under the default REQUIRE_API_KEY=false the client-api
policy admits both a missing and an invalid bearer as anonymous, and the scope comes back
{ apiKeyId: null, isSessionAuth: false }. The /v1/files and /v1/batches routes then read that
null as permissive in two ways:

• GHSA-m3hp (listing): listFiles / listBatches got apiKeyId || undefined, and the DB layer
  treats undefined as "no owner filter". An anonymous or invalid-bearer caller received every
  tenant's file and batch metadata — the same view as the operator's dashboard.
• GHSA-2jm2 (null-owner records): single-record checks were record.apiKeyId !== null && …, so a
  record without an owner was open to any caller.

Route	Before, for a foreign key or anonymous caller
GET /v1/files/[id], /content	null-owner metadata and raw bytes readable
DELETE /v1/files/[id]	null-owner file deletable (content nulled)
POST /v1/batches	foreign key could run a batch over a null-owner input file
GET / DELETE /v1/batches/[id], POST …/cancel	null-owner batch readable / deletable / cancellable
GET /v1/files, GET /v1/batches	every tenant's records

Null-owner records are not rare: every dashboard-session upload is one, and batch output files
inherit the batch's owner, so a session batch produces null-owner files carrying model responses.
api_key_id has existed since migration 028, so these are not legacy rows. Nothing documented them
as shared — API_REFERENCE.md says files are scoped per key — while batch_api.test.ts pinned the
by-id exposure as expected.

Change — one rule, in _helpers/apiKeyScope.ts

• canAccessOwnedRecord(scope, owner) — dashboard session: any record; API key: own records
  only; null owner: denied to every non-session caller. Used by all seven single-record paths above.
• resolveListScope(scope) — an explicit union for list reads: scoped to the presented key (a
  key wins even alongside a session cookie), instance-wide only for a session without a key, 401
  otherwise — including a bearer that does not resolve to a key. No default widens a read.

Same shape as the GHSA-wvxc fix already used by batches/delete-completed.

Behaviour change: the anonymous upload → batch → download flow stops working without an API key,
because a null owner cannot be attributed to anyone.

About #13683

It moved scopeCheck into the shared helper so a session can cancel any batch. That part is kept
here and its test (batch-cancel-session-auth-scope.test.ts) is ported. It also kept null-owner
records open on the premise that they predate ownership tracking, which migration 028 contradicts —
that is the GHSA-2jm2 hole.

Validation (TDD)

Check	Result
New files-batches-ownership-2jm2-m3hp.test.ts (anonymous / invalid bearer → 401, key-scoped lists, session sees all, key+cookie stays key-scoped, null-owner 404, foreign key cannot batch a null-owner input) — on the tip	red
Same file + ported #13683 test + flipped batch_api + batch-deletion-route-logic + delete-completed scope	62 / 62
Files/batches unit suite (522 tests)	522 / 522
integration/files-api-limit-validation	6 / 6
typecheck:core, check:docs-sync	clean
eslint (repo suppressions), prettier	clean

Test adaptations: batch_api's by-id case is flipped to 404 with a negative assertion (it was
pinning the bug); batch-deletion-route-logic now imports the real helper instead of a local copy
that had silently diverged from production; the two integration tests present a real API key, since
their subject is limits and rate logging, not auth.

integration/batch-e2e-rate-limit could not be validated locally: the Next server did not become
ready within the harness timeout on a box at load average 45 (Timed out waiting for server, before
any files/batches code runs). CI should settle it.

⚠️ base-red inherited: #12732 — failures outside the files/batches suites come from the tip.