ii.filesMerge: did O(n^2) re-merge of sequences (chunks of same key)

[AskAlexSharov]

Story: i noticed on profiler that during InvertedIndex files merge deriveFields() fun did many re-allocs. Initially i had intent to 2x over-alloc to amortize it - but realized that we doing multiple merges of same key (multiple chunks from multiple small files) - each such merge produced "bigger sequence". So, clearly higher-level logic of merge files is wrong and need merge all chunks at once.

---

Before: incremental pairwise merge — for a key in N files, reads C + 2C + 3C + ... + NC = O(N²·C) elements and calls EliasFano.ResetForWrite(→ deriveFields → make([]uint64, ...)) N times, allocating a new backing array each time since the merged size always exceeds the previous capacity.

After: single-pass accumulation — collects all N items for the current key, computes totalCount and maxOff in one scan, initialises the builder once with the correct size (so deriveFields only allocates once per key at the right capacity), then iterates the N files in ascending txNum order adding all values in a single pass. O(N·C) reads, O(1) allocations per key.

BenchmarkInvertedIndexMergeFiles:

  ┌───────┬─────────┬─────────┬─────────┐
  │ files │ before  │  after  │ speedup │
  ├───────┼─────────┼─────────┼─────────┤
  │ 4     │ 840 µs  │ 763 µs  │ 1.1x    │
  ├───────┼─────────┼─────────┼─────────┤
  │ 8     │ 1306 µs │ 819 µs  │ 1.6x    │
  ├───────┼─────────┼─────────┼─────────┤
  │ 16    │ 3116 µs │ 970 µs  │ 3.2x    │
  ├───────┼─────────┼─────────┼─────────┤
  │ 32    │ 9718 µs │ 1305 µs │ 7.4x    │
  └───────┴─────────┴─────────┴─────────┘