fix(index): a field holds every value kind it was written with, not the first one

The metadata index fixed a field's value type from the first value it saw.
Every later value of another kind was coerced to that type, and when coercion
failed — `Number('electronics')` is NaN — the value was dropped from the index
with no error at all. The row stayed readable by id and by vector search and
vanished only from equality filters on that one field, which is what made it so
quiet: writing `category: 'electronics'` rows and then `category: 5` rows left
`where { category: 5 }` returning nothing, while the same rows in a
numbers-only corpus answered correctly.

The column store now keeps one posting column per (field, kind), where a kind
is a JavaScript typeof class. The first kind a field sees keeps the historical
`_column_index/<field>/` layout, so a single-kind field is byte-identical to
what earlier versions wrote and an index written before this opens unchanged;
each later kind takes its own column at `_column_index/<field>/k/<kind>/`.

Equality reads the column matching the query value's own kind, so `{c: 5}` and
`{c: '5'}` match different rows and neither is coerced into the other. Ranges
route by the kind of their bounds, and an unbounded range — the "has any value"
probe behind `exists` — reads every kind. A mixed field orders by kind first,
then by value, because a number and a string have no order between them. A
value that cannot be encoded for the column its own kind selected now raises
instead of being skipped: that path is unreachable by construction, and if it
is ever reached it is the silent drop this change exists to end.

Two neighbours fell out of the same routing. A boolean query value is now
encoded to the 1/0 the column stores, so boolean equality matches at all. And
an integer column widens to f64 the first time a non-integer arrives, so 4.5 is
stored as itself rather than rounded to 5 and answering the wrong query.

Field type inference reports every kind a field holds beside its dominant
reading, rather than leaving callers to treat one type as the whole answer.

Pins: mixed-kind equality in both write orders, `5` vs `'5'`, booleans mixed in,
a numeric range over a mixed field's numbers, close/reopen keeping every typed
posting, and an index in the pre-existing on-disk shape still reading.
`tests/critical-neural-validation.test.ts` — which writes `category` as strings
in one test and as numbers in another against one shared brain — passes whole
for the first time.

(cherry picked from commit a128f0eda5)

docs/architecture/data-storage-architecture.md

@@ -217,6 +217,40 @@ membership queries at scale:
   `__words__` for tokenized text…).
 - `_blobs/_column_index/{field}/L0-NNNNNN.bin` — the actual level-0 run
   segments, stored through the shared `_blobs/<key>.bin` binary convention.
+- `_column_index/{field}/k/{kind}/…` — the same two files again, for a
+  **second value kind** on the same field (see below). Absent for a field that
+  holds one kind, which is nearly all of them.
+
+### One posting column per (field, kind)
+
+A field is not obliged to hold one type of value. `category` may carry
+`'electronics'` on some rows and `5` on others, and both are real values of
+that field. A segment, though, has one encoding — i64, f64, UTF-8, or boolean
+— so a field that holds several kinds gets **one column per kind**:
+
+- The first kind a field ever sees owns the plain `_column_index/{field}/`
+  layout above. A single-kind field is therefore byte-identical to what earlier
+  versions wrote, and an index written before typed postings opens unchanged.
+- Every later kind gets its own column beside it at
+  `_column_index/{field}/k/{kind}/`, where `{kind}` is `number`, `string` or
+  `boolean`.
+
+What that buys at query time:
+
+| | |
+|---|---|
+| **Equality** | Answered from the column matching the **query value's own kind**. `where {category: 5}` reads the number postings; `where {category: '5'}` reads the string postings. Neither borrows the other's rows — a row written with the number `5` is not a row whose category is the text `'5'`. |
+| **A kind the field never held** | Matches nothing. That is the true answer, not a coerced one. |
+| **Ranges** | Routed by the kind of the bounds: numeric bounds read the numeric postings and ignore the field's strings. An **unbounded** range is the "has any value here" probe behind `exists`, and reads every kind. |
+| **`orderBy`** | A number and a string have no order between them, so a mixed field orders by kind first (number, string, boolean) and by value within a kind. A single-kind field sorts exactly as it always did. |
+| **Numbers** | One kind, one column: an integer column is written as i64 and widens to f64 the first time a non-integer arrives, so `4.5` is stored as itself rather than rounded. |
+
+`null` and `undefined` are not kinds and are never posted; their absence is
+what the `exists` / `missing` operators read.
+
+Older readers are unaffected by the additional columns: they see the field's
+primary column exactly where it has always been, and a `k/{kind}` directory is
+simply a name they never query.
 
 Sparse per-field indexes, roaring-bitmap chunks, and zone-map/bloom segments
 additionally live as bucketed keys under `_system/idx/` (see §3). Which path