fix(db): forward-progress guard in both deleteCompletedBatches chunk loops (#13377)

[jonlwheat2-gif]

Summary

Stacked on #13374 (fix/batches-sweep-file-ownership-chunks). Adds the forward-progress guard that issue #13377 asks for in both for (;;) loops of deleteCompletedBatches.

Base note. This PR targets fix/batches-sweep-file-ownership-chunks (the head branch of #13374) because the two chunked loops only exist there — #13377's wording ("forward-progress guard in both for (;;) loops") is written against #13374, not against release/v3.8.51.

Why

Both loops walk completed batches in chunks of INSTANCE_SWEEP_CHUNK:

SELECT id FROM batches WHERE status = 'completed' [AND api_key_id = ?]
ORDER BY rowid LIMIT ?

Each iteration sweeps its chunk (file soft-deletes + checkpoint DELETE + batch DELETE) and then re-selects the next chunk. If a DELETE ever fails to make progress — a concurrent deleter holding the same rows, or a swallowed no-op delete — the same chunk is returned forever and the request thread spins.

Change

src/lib/db/batches.ts — +23 lines, one guard per loop:

• remember the first id of the previous chunk;
• throw when the next chunk starts with the same id:

deleteCompletedBatches: chunk sweep made no forward progress (first id repeated)

Failure semantics stay consistent with each mode:

Mode	On throw
key ({ apiKeyId })	whole sweep runs in one outer transaction → everything rolls back
instance ({ allTenants: true })	commits per chunk (SEC-D) → earlier chunks stay committed, current chunk rolls back, rethrow

Verification

• git diff against 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's head is exactly the 23 added lines, src/lib/db/batches.ts only
• file parses clean (node --experimental-strip-types --check)
• the guard only fires on a genuine no-progress chunk, so the existing batch-deletion suites are unaffected; CI runs the full suite against this base

Related

• chore(auth,db,skills): hygiene follow-ups from the omni-review closeout final reviews (#13375, #13374) #13377 — tracking issue (this covers its "Batches sweep" bullet)
• 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 — base PR: chunked instance sweep + owner-scoped file half
• fix(api): scope batch bulk-delete to the calling API key #12969 — base of 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 (currently CONFLICTING; needs a rebase before this stack can land)
• chore(auth): hygiene follow-ups from omni-review closeout (#13377) #13567 — the auth-only half of chore(auth,db,skills): hygiene follow-ups from the omni-review closeout final reviews (#13375, #13374) #13377
• fix(build): keep node:fs out of the client chunk graph (Turbopack /login + /dashboard) #13568 — separate Turbopack dev-server fix (node:fs in the client chunk graph)

[jonlwheat2-gif]

CI note. No pull_request workflows ran for this PR: the CI triggers are scoped to release/** and the default branch, so a base of fix/batches-sweep-file-ownership-chunks doesn't match. The only check that fired is semgrep (pass).

Checks will run once this is retargeted to release/v3.8.51 (or via #13374's own CI). Note that the release/v3.8.51 checks are currently red repo-wide — every open PR against it (#13565, #13566, #13571) shows the same failures.

Local verification of this change: the diff against #13374's head is exactly the 23 added lines in src/lib/db/batches.ts, and the file parses clean.