fix: Windows could never boot + autoindex WAL-fd bound, gated by a per-platform CI matrix - #84

`fsync_dir` opened the directory with `std::fs::File::open`, which on
Windows always fails with ERROR_ACCESS_DENIED (os error 5) — std cannot
pass FILE_FLAG_BACKUP_SEMANTICS, so a directory handle is unobtainable.
It is called from `IndexStore::save_snapshot`, so *every* index creation
returned an I/O error, and the unconditional xerj-console bootstrap made
that fatal at startup:

    Error: xerj-console bootstrap
    Caused by: internal: create .xerj_users: storage error:
               I/O error: Access is denied. (os error 5)

Every published Windows binary since the durability chain landed in
297be60 (2026-07-12 — shipped in rc.4 through rc.8) has therefore been
unable to create an index or boot at all, while xerj.org/get.ps1 kept
installing it. Nothing caught it because no CI job had ever executed the
binary on Windows; the new per-platform smoke job is what surfaced it.

Windows exposes no directory-flush primitive (FlushFileBuffers is not
defined for directory handles), so the Windows body returns Ok(()).
Durability there rests on the file-level sync_all the callers already
perform plus NTFS metadata journalling of the rename — weaker than the
Unix guarantee, and now documented as such rather than silently failing.

Also assert a create-index / index-doc / search round-trip in the
per-platform smoke script. Autoindex alone would have caught this, but
only as an opaque "server exited during boot"; the explicit round-trip
names the failing operation on whichever platform breaks next.

THE MAP shipped on two load-bearing claims — "13 groups at any scale"
and "byte-identical across runs" — with no automated test in any
language behind either. The only exercise was a manual Puppeteer script
needing a live server, a token argv and a real Chrome, so in practice
nothing checked them.

The clustering pipeline is pure, dependency-free ES module code, so its
contract is checkable offline in ~600ms. 23 cases over four corpus
scales (8 / 12 / 40 / 120 folders — straddling the 12-cluster cap):

  * clusters.length never exceeds MAP_TOP_CLUSTERS + 1, with at most
    one pooled "everything else" body
  * every file-node lands in exactly one group, and the membership
    lists agree with clusterOfFile in both directions
  * fetched links reconcile: Σ merged-link constituents + selfLoops
    equals the input row count, which is the invariant the honesty row
    on the UI is computed from
  * the same rows produce a byte-identical partition across runs
  * bundles stay under the C·(C−1)/2 pairwise bound
  * as-of replay: a link retired before the queried instant counts
    toward the total but not toward live, and replaying to before its
    retirement makes it live again

All pass against the current pipeline — these are regression guards,
not bug reports. Wired as a `ux-tests` job (node --test, no build, no
server).

…ount

`cargo test --workspace` fails on any developer machine with real core
count and passes on CI, which is why nobody has seen it:

  reindex_pages_past_10k_via_keyset
  assertion `left == right` failed: every source doc must be reindexed
    left: 0
   right: 10050

The test seeds via `index_batch_turbo(batch, parallel = true, ..)` and
then asserts on the reindex output without refreshing. Turbo ingest
routes docs to memtable shards BY WORKER THREAD, so on a 2-core runner
every doc lands in one shard and is incidentally visible to the search
the reindex pages over — 10050/10050, green. With real core count the
docs scatter across unpublished memtable shards and the same search
sees nothing at all, so the destination gets 0. The sanity assertion
above it passes either way because `live_doc_count` reads the version
map, not the search surface.

Refreshing the source before the reindex makes the test measure paging
— which is what it is named for — instead of the host's CPU count.
Verified green under both `taskset -c 0,1` and the full core count.

The product path is NOT affected: driving the real HTTP surface end to
end (bulk 10050 docs, POST /_reindex with size 1000) reports
`total: 10050, created: 10050, batches: 11` and the destination counts
10050, both with and without an explicit `_refresh` first. This is the
test reaching under the API, not a reindex defect.

Pre-existing — reproduced on plain main (7e050d0), not introduced by
the FD or hardening work. Same blind spot as the rc.4 doc-values bug:
2-core CI runners cannot see shard-scatter behaviour.