fix(metadata-protocol): a seam that cannot answer is absent, not empty (#10789) (#10964)

`backfillSeedTenancy` reported `no-split` over a driver it never queried. A
no-op `execute` returns `null` — it neither throws nor is absent — so the
`no-driver` guard's shape test passed, `normalizeRows(null)` flattened to `[]`,
and the module's own `absent` branch was unreachable on a memory engine despite
its comment naming exactly that case.

The READ probes are now held to the standard that separates the two: a driver
that answers returns a RESULT SET. Write statements stay on the bare seam (an
UPDATE returns no result set on every dialect), a throwing seam keeps its
existing `absent` route, and an empty result set in all three dialect spellings
is still an ANSWER — so a healthy SQL install still reports `no-split`.

Consumer-side only; no driver package was modified (#5499 freeze).


Claude-Session: https://claude.ai/code/session_019yDEhPBC3tcGkW9bkce1HM

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

Author: Elon Musk

.changeset/seed-tenancy-absent-seam.md

@@ -0,0 +1,45 @@
+---
+"@objectstack/metadata-protocol": patch
+---
+
+`backfillSeedTenancy` no longer reports `no-split` over a driver it never queried
+(#10789). The boot-time seed/API tenancy repair answered `status: 'no-split'` —
+*"I looked, there is no split"* — on the memory driver, having looked at nothing,
+and its own `absent` branch was unreachable there despite the branch's comment
+saying *"Absent on a memory engine"*.
+
+`InMemoryDriver.execute()` logs `Raw execution not supported in InMemory driver`
+and returns `null`. It neither throws nor is absent, so `resolveSeedTenancySeam`'s
+shape test (`typeof d.execute === 'function'`) was satisfied and the `no-driver`
+guard never fired; `normalizeRows(null)` is `[]`, which is also what a real driver
+returns for a SELECT that matched nothing. Every branch of this migration reads
+"no rows" as "healthy install, nothing to do", so the two collapsed into one
+answer.
+
+The migration now separates the cases the guard used to conflate: **a seam that
+cannot answer is absent, not empty.** Its READ probes are held to the standard
+that actually distinguishes them — a driver that answers returns a RESULT SET —
+so a probe that hands back no result set reports `absent` (with a `detail` naming
+the reason) instead of being read as zero rows. Nothing names a driver: any host
+with the same no-op shape is covered without an allowlist to maintain. This is the
+consumer-side shape #10677 / PR #10788 landed for `os migrate duplicates`, applied
+to this module's own probes. No driver package was modified.
+
+Three behaviours are deliberately unchanged:
+
+- **A real SQL install does not move.** An empty result set is an ANSWER in every
+  dialect spelling — a bare `[]`, `{ rows: [] }`, and the `[rows, fields]` tuple —
+  so a healthy install still reports `no-split`. The counter-table presence probe
+  is a `WHERE 1 = 0` SELECT that matches nothing by construction and runs on every
+  boot, which is exactly why "no rows" must stay distinct from "no answer".
+- **Write statements are not held to "must answer".** An UPDATE or DELETE does not
+  return a result set on every dialect, so the repair's stamp and counter-merge
+  statements stay on the bare seam.
+- **A seam that THROWS keeps its behaviour.** Throwing is a driver present and
+  refusing loudly, and step 1's `catch` already reported it as `absent`; only a
+  seam that RETURNS a non-answer was invisible.
+
+Boot-time behaviour is otherwise untouched: neither status logs anything, and
+neither writes a ledger receipt, so a memory-driver boot logs exactly what it
+logged before. What changes is the reported `status`, which is the value a caller
+uses to tell "nothing to repair" from "could not look".