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.