perf(open): answer "are there any entities?" with one directory read

The 7.x-to-8.0 layout probe runs on the open path of every store that does not
yet carry its completion marker — a restore, a store built by an older release
— and asked whether the canonical tree holds anything by LISTING it: a
recursive walk of every file in every entity directory, to learn a boolean. It
now asks the one-level door added for generation discovery, falling back to the
listing on an adapter that lacks it.

Also files a defect found while ratifying the operator set: the VFS builds its
path-prefix filter as `$startsWith`, an operator no engine spelling accepts,
so vfs.searchFiles({ path }) throws INVALID_QUERY on every call that passes a
path. Pre-existing, unrelated to the operator work, and left as a filing —
a path-prefix search needs a design answer, not a spelling correction.

docs/contract-1-ratification.md

@@ -219,6 +219,21 @@ every door contract 1 requires?" — is a set-membership check between their
 
 ---
 
+## A defect this work surfaced but did not fix
+
+`src/vfs/VirtualFileSystem.ts` builds a path-prefix filter as
+`path: { $startsWith: options.path }` — with a `$` prefix. No operator in this
+engine carries a `$`, so `validateWhereFilter()` rejects it with
+`INVALID_QUERY` before any index read: **`vfs.searchFiles({ path })` throws
+today, on every call that passes a path.** It is pre-existing and unrelated to
+the operator work above (the validator refuses it before the index path is
+reached), and it is left as a filing rather than fixed here, because the right
+answer is a design question — a path-prefix search cannot be served by an
+equality/range index, so it needs either a path-segment index or an explicit
+in-memory narrow, not a spelling correction.
+
+---
+
 ## Summary of what changed in code for this ratification
 
 | item | change |