[beinan]

Parallel WAL shard merges repeatedly fail on table-wide CreateIndex transactions because each merge creates or extends the key index before deleting and appending rows. Move index publication out of WAL merges: use bounded typed-key predicate deletes for BTree and ZoneMap, reading only keys and row IDs from uncovered fragments. Explicit index maintenance remains available; index defaults, ownership, WAL byte limits and publication fencing are unchanged.

Regression coverage includes absent/partial indexes, explicit index extension, quoted keys and 1,024-key chunks, replay, and four concurrent shard updates with complete payload verification for both index types. All 291 core tests passed (14 pre-existing ignored tests); Clippy and the initial parallel regression passed. The strengthened four-shard regression also passed in the combined staging tree: both indexed and uncovered existing rows are updated, every payload is verified, physical row counts remain correct, replay is empty and index identity is unchanged.

An isolated Azure comparison passed eight fixtures and replay/ID/revision checks with no OOM. Three-batch BTree time decreased from 3.09 to 2.66 seconds (262k keys) and 3.42 to 2.75 seconds (256 MiB base payload); ZoneMap differences were small. This is a serial synthetic component measurement, not fleet throughput. BTree large-payload peak RSS increased by about 68 MiB. Deferred coverage can increase key scans on long-running tables, so scheduled index maintenance remains necessary. Reproduction and complete measurement scope are documented.