plan/spec: M3's row is closed

All five steps of the index-types review landed:
the refusal, the recorded corpus, partial indexes, hashed indexes, and
the implication test. `tests/spec/indexes/` is 48/48 and all four
recorded corpora are green -- positional 51, operators 125, indexes 48,
aggregate 70.

The review gets a fourth correction, and it is about method rather than a
fact. §4 asserted the implication rule without saying how to test it; the
answer needed no comparison of its own, because every operator the
partial-filter grammar admits is existential, so running the real matcher
against a stand-in document settles five operators at once.

What the review missed entirely was the gates. A corpus recorded from
mongod can see an implication test that says yes too readily -- documents
go missing -- but not one that never says yes, because no client can
observe which index a read used and this server has no `explain`. Both
numbers are recorded in PLAN §6 and the corpus README so the next change
to this code knows which gate is load-bearing for which direction.

Nothing else in M3 remains. PLAN §6 still carries the items this row
turned up and deliberately left: comparison operators are not
type-bracketed, a dotted path through an empty array reads as absent, a
key-pattern direction may be any non-zero number, three positional
divergences, three operator omissions, and the four older engine items.

tests/spec/indexes/README.md

@@ -50,7 +50,7 @@ halves have since been driven green:
 
 ```
 hashed.json    18 pass    0 fail   0 skip
-partial.json   24 pass    0 fail   0 skip
+partial.json   30 pass    0 fail   0 skip
 ```
 
 The three that passed at the start were the reads a partial index does not
@@ -63,6 +63,24 @@ to match a document with no `a`, and this server matched only an explicit
 null — with or without an index. No other test in the repository asks, and
 the pinned crud+aggregate scorecard did not move when it was fixed.
 
+## What this corpus cannot see
+
+Six of `partial.json`'s cases exist for the implication test — the rule that
+lets a partial index answer a read — and it is worth being exact about what
+they guard, because it is only half of it.
+
+A partial index holds a subset, so reading from one the query does not imply
+returns **too few** documents, and that is an answer a result comparison
+catches. It was measured: forcing the implication test to always say yes takes
+this file to 23 pass / 7 fail, every failure reading "expected N, got N-1".
+
+The other direction is invisible here. Forcing it to always say *no* — the
+behaviour before the test existed, where a partial index was maintained and
+never read — leaves this file at **30 pass / 0 fail**. No client can observe
+which index a read used, and this server has no `explain`. So the corpus
+guards soundness and a unit test on `plan()` is the only thing that sees the
+feature work at all.
+
 ## What recording it settled
 
 Two of the review's own guesses were wrong, which is why it was recorded