plan/spec: partial indexes are done, hashed is next

partial.json 3/24 -> 24/24, hashed.json still 0/18. PLAN §6 records the
planner rule that is deliberately left conservative -- a partial index is
maintained and enforces `unique`, and reads scan until the implication test
exists.

Full matrix at this commit: 250/250 unit tests in ReleaseFast and ReleaseSafe,
83/83 fuzz, operators 125/0, positional 51/0, aggregation 70/0, pinned crud
228/63/196, e2e and crash-fuzz green.

PLAN.md

@@ -1143,6 +1143,16 @@ has to be its own commit with its own re-recorded scorecard.
   contrast, was honestly missing -- refused, with the wrong code (2 where
   mongod says 67) but the right answer.
 
+  **Partial indexes landed**; `partial.json` is 24/24. The filter is consulted
+  in one place, `build_entries`, so the insert and the remove path cannot
+  disagree about which documents the index holds -- and `unique` then comes
+  out right for free. Persisted through a fifth flag bit in
+  `write_index_catalog` with `catalog_version` still 1. **The planner declines
+  to read from a partial index**: it holds a subset, so answering a query from
+  it is only correct when the query implies the filter, and that implication
+  test is the last step of the row. Too few documents is worse than no index.
+  Left open with it: `hashed.json` is still 0/18.
+
   **`tests/spec/indexes/` is the gate**, recorded red at 3/39 across 42 cases.
   A case there is a *sequence* -- create, insert, read, list -- because an
   index outlives a `deleteMany` and every case is about which indexes exist.

tests/spec/indexes/README.md

@@ -37,16 +37,17 @@ first that throws, which is what a client would see.
 
 ## Where it stands
 
-Recorded against mongod 8.3.7, run before any of it was implemented:
+Recorded against mongod 8.3.7 at 3/39 -- red by construction -- and partial
+indexes have since been driven green:
 
 ```
 hashed.json     0 pass   18 fail   0 skip
-partial.json    3 pass   21 fail   0 skip
+partial.json   24 pass    0 fail   0 skip
 ```
 
-Red by construction. The three that pass are the reads a partial index does
-not change: this server builds an index over every document, so a query still
-finds everything, which is the whole reason the review called the partial gap
+The three that passed at the start were the reads a partial index does not
+change: this server indexed every document, so a query still found
+everything, which is the whole reason the review called the partial gap
 smaller than the `arrayFilters` one.
 
 ## What recording it settled