fix(objectql): bound every lifecycle reap, not just the guarded ones (#5194)

`LifecycleService.reap()` issued a single unlimited `delete(..., { multi: true
})` per sweep on any object without a registered reap guard — no limit, no
paging. Batching lived only on the two side paths, `guardedReap` and the
Archiver (both 500 x 20 per sweep), whose comment states the reason plainly:
"bound one sweep's work, drain the backlog across sweeps". That reason never
depended on a guard being registered.

Steady state was never the problem — an hourly sweep deletes a small increment.
The cost landed exactly once per table, on the first sweep after `retention` is
declared on a table that already holds history: one DELETE scanning every
historical row. SQLite holds the whole database's write lock for its duration;
Postgres takes it as autovacuum debt.

Unguarded reaps now run the same batched machinery the guarded ones do, rather
than a second copy of it. An object with no guard is the EMPTY guard
intersection, which confirms every candidate row, so `guardedReap` already
computed the right answer for it — the guard loop just does not execute. It is
renamed `batchedReap` because bounding the work, not consulting guards, is what
it is for. One reap path, one place where a reap decides what to delete.

Three things the unification had to settle, each pinned by a test:

- An id-less candidate row is dropped before the guards see it. With guards,
  the intersection dropped such rows as a side effect of matching ids; with
  zero guards nothing narrows, and `where: { id: undefined }` with `multi: true`
  is not a by-id delete at all — the engine's dispatch finds no scalar id and
  routes to deleteMany over the batch's whole cutoff predicate.
- The paging loop checks the #4747 abort bit per page. `sweep()` checks it
  between objects, which was the whole story when an unguarded reap was one
  `await`; it is now up to 20 pages of reads and deletes.
- An engine with no `find` cannot page, so it keeps the previous single bulk
  DELETE. That is the no-`find` path, not the unguarded path: losing retention
  enforcement entirely would be the worse trade, and no guard is waiting to
  confirm anything. Every real engine has `find`.

Cutoff and `retention.onlyWhen` predicates are unchanged and now select the
candidate read; the report's `deleted` count reflects rows actually deleted.
Cost of the bound, stated in the file: one afterDelete hook per reaped row
instead of one per object per sweep. No platform object changes its audit
output — all of them are in the audit writer's SKIP_OBJECTS, and `sys_file`,
the one that is audited, already reaped per id via its guards.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V7WetGmnfoXNn8cLieKKmx

Author: claude

.changeset/lifecycle-unguarded-reap-batching.md

@@ -0,0 +1,37 @@
+---
+'@objectstack/objectql': patch
+---
+
+fix(objectql): bound every lifecycle reap, not just the guarded ones
+
+`LifecycleService.reap()` issued a single unlimited `delete(..., { multi: true })`
+per sweep for any object without a registered reap guard — no limit, no paging.
+Batching existed only on the two side paths (`guardedReap` and the Archiver,
+both 500 × 20 per sweep), whose comment gives the reason plainly: "bound one
+sweep's work, drain the backlog across sweeps". That reason never depended on a
+guard being registered.
+
+Steady state was fine — an hourly sweep deletes a small increment. The cost
+landed exactly once per table, on the first sweep after `retention` is declared
+on a table that already holds history: one DELETE scanning every historical row,
+which on SQLite holds the whole database's write lock for its duration and on
+Postgres arrives later as autovacuum debt.
+
+Unguarded reaps now run the same batched machinery the guarded ones do — an
+object with no guard is simply the empty guard intersection, which confirms
+every candidate row — so there is one reap path rather than two parallel ones.
+Candidates are read a page at a time and deleted by id, at most 500 × 20 rows
+per object per sweep, with the remainder draining on later sweeps. Cutoff and
+`retention.onlyWhen` predicates are unchanged; they now select the candidate
+read. The sweep report's `deleted` count reflects rows actually deleted this
+sweep.
+
+Two consequences worth knowing:
+
+- A reap fires one `afterDelete` hook per reaped row instead of one per object
+  per sweep. Every lifecycle-declaring platform object is in the audit writer's
+  `SKIP_OBJECTS`, and `sys_file` already reaped per id via its guards, so no
+  object in the platform changes its audit output.
+- An engine that does not implement `find` cannot page and keeps the previous
+  single bulk DELETE, so retention enforcement never silently stops on it. Every
+  real engine implements `find`.