Random LMDB key insertion order causes B-tree performance degradation

During vector index writes, the current implementation iterates layers (outer loop) then HashMap items (inner loop, unordered), causing LMDB keys to be inserted in random order. This triggers maximum B-tree page splits and rebalancing, poor cache locality, and O(log N) insertion cost instead of O(1) amortized when keys arrive sorted.

Pre-sort entries by key before writing to LMDB. Collect all entries into a vector, sort by key (item_id primary, layer secondary to match LMDB's lexicographic order), then write sequentially. For optimal performance, use LMDB's APPEND flag (similar to facet bulk.rs pattern in milli) when keys are guaranteed sorted, which skips B-tree search entirely. Requires deleting old links first before writing sorted new links.