fix(objectql): retire sys_fetch_previous_delete so the delete-path per-object gate is honest (#5929) (#6794)

* fix(objectql): retire `sys_fetch_previous_delete` so the delete-path per-object gate is honest (#5929)

`delete()`'s prior-row read is gated per object on
`hasHooksFor('beforeDelete', object) || hasHooksFor('afterDelete', object)
|| getSummaryDescriptors(object).length > 0`. On any kernel-hosted engine the
first term was constant true, because `ObjectQLPlugin` registered its own
`sys_fetch_previous_delete` builtin with `object: '*'` — so the per-object skip
the gate exists to perform never happened outside the bare engines unit tests
boot.

The builtin could not use what it held open. Since #5272 (by-id) and #6697
(predicate path, per matched row) the engine reads the pre-image and binds
`previous` before `beforeDelete` dispatches, so its `!ctx.previous` guard was
permanently false and it issued no read. Its only remaining effect was holding
open the gate that made it redundant. Retired under ADR-0049 enforce-or-remove;
the measurement #5846 recorded in `plugin.ts` was re-verified on this branch
rather than taken on trust.

The gate's three terms are unchanged — no term was added or removed. What
changed is that term 1 now reflects real hooks. `engine.ts` gains the
enumeration of the delete-phase hooks that still register globally
(plugin-auth, plugin-sharing, service-storage; plugin-audit narrows at the
engine face with `excludeObjects`), so nobody reads a skip into a trace that
will not show one.

New `engine-delete-prior-read-scope.test.ts` pins the three terms per object,
the `excludeObjects` subtraction on both phases, the predicate path's twin
gate, and — on a real `ObjectKernel` + `ObjectQLPlugin`, the only configuration
where the defect was observable — the zero-read skip and the still-bound
`previous`. It replays the retired builtin's own shape and measures its guard
short-circuiting, so "the guard can no longer be true" stays a measurement.

The by-id `beforeDelete` REPOINT behaviour is deliberately untouched (#6752).

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

* test(objectql): keep the new delete-gate pins inside the erasure ratchets (#5929)

Two lint.yml gates caught the new test file on the first full run:

* `check:slot-lookup` / `no-restricted-syntax` — `kernel.getService('objectql')
  as any` erased the slot's contract for every `engine.*` call in the kernel
  section, which is where the measurement lives. Typed as
  `getService<ObjectQL>('objectql')`.
* `check:query-options-erasure` — three `count(obj, {} as any)` calls grew the
  test-surface count 263 → 266. The empty options bag is already on contract;
  the assertion was never needed.

No assertion changed; the file still passes 16/16.

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

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-zhuang

.changeset/retire-delete-fetch-previous-builtin.md

@@ -0,0 +1,49 @@
+---
+"@objectstack/objectql": patch
+---
+
+fix(objectql): retire `sys_fetch_previous_delete`, so `delete()`'s per-object prior-row gate is a real question (#5929)
+
+`delete()` reads the doomed row's pre-image only when something on **this
+object** consumes it — a delete-side hook in either phase, or a roll-up summary
+aggregating it. That gate has been per object since #5272, and on a
+kernel-hosted engine it was **constant true for every object that has ever
+existed**, so the skip it exists to perform never happened outside the unit
+tests' bare engines.
+
+The reason was `ObjectQLPlugin`'s own builtin. `sys_fetch_previous_delete`
+registered on `beforeDelete` with `object: '*'`, which made the gate's first
+term true everywhere — and it could not use what it held open: since #5272 (and
+#6697, which extended the same ordering to the predicate path, per matched row)
+the engine reads the pre-image and binds `previous` **before** `beforeDelete`
+dispatches, so the builtin's own `if (input.id && !ctx.previous)` guard was
+permanently false and it issued no read. Its only remaining effect was holding
+open the gate that made it redundant. Retired under ADR-0049
+enforce-or-remove.
+
+**What changes for you, in both directions:**
+
+- An object with **no** delete-side hook and no roll-up summary now performs
+  **no prior-row read** on a by-id `delete()`. Previously it always did, on any
+  kernel.
+- Where a delete-side hook **does** exist, `previous` still arrives bound,
+  identically — from the engine's own read, which was already the only producer.
+  Hook handlers, declarative `condition`s reading `previous`, the record-change
+  trigger, the audit diff and the summary recompute are all unaffected.
+- The residual shape the retired guard could still have been true for — the
+  engine's read found nothing because the row is already gone — is one where the
+  builtin's read found nothing either, so it binds nothing there too. `previous`
+  stays **unbound** rather than fabricated as `{}`, unchanged (#4649/#4775).
+
+Nothing about hook dispatch, the by-id repoint re-resolution, or the delete
+dispatch ladder changes. The gate's three terms are unchanged — what changed is
+that its first term now reflects **real** hooks.
+
+One caveat worth stating so nobody reads a skip into a trace that will not show
+one: a kernel that also loads plugin-auth, plugin-sharing or service-storage
+still has the gate held open on every object, because each registers a
+delete-phase hook with no `object` and decides applicability inside its handler.
+Those are real consumers, not circular ones. plugin-audit is the exception and
+the worked example — it narrows at the engine face with `excludeObjects`
+(#5860), so an excluded object really does skip the read. The full enumeration
+is in `engine.ts` beside `wantsPreImage`.