fix(driver-sql): refuse an unresolvable WHERE column on both find() and count() (#8790) (#8927)

* fix(driver-sql): refuse an unresolvable WHERE column on both find() and count() (#8790)

One predicate had two answers: the #3821 ladder's rungs all re-apply
`query.where`, so a WHERE-side unknown column could never be recovered and
fell to `return []`, while `count()` — which has no ladder — threw the
dialect's own error with the bound literals inlined.

Both halves now refuse with the ADR-0112 envelope this path already declares:
`INVALID_FILTER` / 400, naming the column. The dialect message goes to the
server log instead of the caller. The ladder's projection and ORDER-BY
recoveries are deliberately untouched — only the WHERE-failure terminal
becomes a refusal (maintainer ruling 2026-08-15).

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

* test(driver-sql): type the refusal suite's queries as DriverQuery

`check:query-options-erasure` measured the new suite growing the test
surface 240 -> 256: sixteen `as any` casts on the query argument. That is
the erasure `DriverQuery` exists to prevent — its own docblock records that
a direct caller holding only a `where` reached for a blanket cast and lost
`where`'s type with it. Typed instead of ceiling-raised; the ratchet is back
at 240.

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

* test(driver-sql): scope the refusal pins to plain columns; record the dotted key per dialect

Live-measured on PG 16.13 and MySQL 8.0.46 (origin/main vs this branch): the
three dialects do not agree on what a dotted key IS. knex compiles
{'title.x': v} to the qualified reference "title"."x", so Postgres reads
`title` as a TABLE and raises undefined_table (42P01), not undefined_column
(42703) — a shape the classifier does not match and never has. On Postgres a
dotted key therefore raised a raw 42P01 on BOTH halves before this card and
after it, byte for byte; the card's headline repro is SQLite-specific.

The refusal pins now cover the RULED scope (a plain column the table lacks),
which holds on both recognised dialects. The dotted key is RECORDED per
dialect in DOTTED_STATUS_QUO with #8371 — the open FILTER-axis dotted-path
verdict — named as the owner, plus a both-halves-agree assertion that is true
whichever way #8371 lands. No classifier change: teaching it 42P01 would mint
a dotted-path verdict at the driver and pre-empt that card.

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

---------

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

Author: hotlong

.changeset/driver-sql-unresolvable-where-column-refused.md

@@ -0,0 +1,91 @@
+---
+"@objectstack/driver-sql": minor
+"@objectstack/spec": minor
+---
+
+fix(driver-sql): one unresolvable WHERE column, one answer — `find()` and `count()` both refuse with `INVALID_FILTER` / 400 naming the column (#8790)
+
+**BREAKING** accept-set narrowing on a GA public data API, shipped as `minor`
+under the lockstep launch-window convention. The migration prescription is
+registered under protocol major 18, where `os migrate meta` users will look.
+
+<!-- adr-0087: registered driver-sql-unresolvable-where-column-refused -->
+
+## The defect
+
+One predicate had two answers. `SqlDriver.findRows()` carries the #3821
+unknown-column recovery ladder, and every rung of it is built from
+`buildBase()`, which **always re-applies `query.where`**. So the ladder can drop
+a projection and can drop an ORDER BY, but it can never drop the clause that
+actually failed when the unresolvable column is in the WHERE — both rungs raise
+the same error and the method fell to `return []`. `SqlDriver.count()` runs a
+separate statement and has no ladder at all, so the identical predicate threw.
+
+Measured on a real `SqlDriver` over better-sqlite3, one table, one seeded row:
+
+```
+where { 'title.x': 'y' }
+  find()   ->  0 rows, NO ERROR
+  count()  ->  THREW  code=SQLITE_ERROR  status=undefined
+               select count(*) as `count` from `task` where `title`.`x` = 'y'
+                 - no such column: title.x
+
+CONTROL  where { title: 'Design' }
+  find()   ->  1 row
+  count()  ->  1
+```
+
+A list view calls both halves, so one query produced an empty page from the rows
+half and a 500-shaped failure from the total half. A caller reading only the rows
+got a silent empty page that says "no records exist" for what was really "your
+predicate never ran" — the single most AI-legible failure to get wrong, since an
+agent reads "no matching records" and writes its next query on that belief.
+
+The thrown half was no better: the dialect's own `code`, no `status` (so an
+unclassified 5xx at the REST boundary rather than a caller mistake), and the
+statement's **bound literals inlined in the message** — the same predicate-text
+disclosure shape #7929 redacted elsewhere.
+
+## The fix
+
+Ruled 2026-08-15 on #8790: **refuse both halves** with `INVALID_FILTER` / 400,
+naming the column. That envelope is not minted here — it is what every sibling
+refusal on this path already answers, required on both SQL drivers by
+`cross-field-conformance-cases.ts` and pinned by
+`sql-driver-boolean-identity.test.ts` and
+`sql-driver-cross-field-conformance.test.ts`. What closes is a
+declared-vs-enforced gap, not a new posture.
+
+The caller-visible message names the column and the object and nothing else. The
+dialect's own message — the compiled statement, bound literals and all — goes to
+the **server log** instead, so the operator keeps the debugging aid that
+`count()`'s raw throw used to provide without it reaching the caller.
+
+**The #3821 ladder keeps both of its recoveries.** Only the WHERE-failure
+terminal `return []` became a refusal, and the asymmetry is the ruling rather
+than an oversight: "rows matter more than their order" is an argument about how
+rows are *presented*, and it does not transfer to a predicate. A dropped sort is
+a correct answer in an unhelpful order; a dropped WHERE is records the caller
+explicitly excluded. Recover-both was rejected for exactly that reason.
+
+## Reach, stated rather than assumed
+
+The refusal fires on the wordings the ladder has always recognised — SQLite
+(`no such column: x`) and Postgres (`column "x" does not exist`). MySQL spells
+the condition `Unknown column 'x' in 'where clause'`, which neither arm matches,
+so on MySQL an unresolvable column still travels out as the raw dialect error.
+That gap is pinned as a fact in the new suite and filed separately: widening the
+predicate would also hand MySQL the #3821 projection and ORDER-BY recoveries it
+has never had, which is an accept-set change in the opposite direction from this
+one.
+
+## Who is affected
+
+Callers that reach the driver with a filter key the table has no column for. The
+ingress doors already refuse this where they can judge — `assertFilterFieldsExist`
+(`@objectstack/metadata-protocol`) answers `INVALID_FIELD` / 400 for everything
+reaching `findData`, with the sentence this refusal now echoes verbatim: *a
+filter on a field that does not exist can only match zero records, so the query
+was refused instead of answered with an empty list*. What changes is the
+backstop underneath them: a registry the door could not read, and a dotted key
+judged on its head segment only.