Per-range madvise on one big mmap splits the VMA and can exhaust vm.max_map_count; advise one contiguous region instead

A file reader that maps a whole file once, then calls madvise(MADV_RANDOM) separately for each segment's data range, makes the kernel split the single VMA at every range boundary. That is about 2 new VMAs per segment, per open. A process that repeatedly opens a file with ~2000 segments hit vm.max_map_count (default 65530) after about 17 opens, and new mmaps then fail with ENOMEM.

Fix: lay the file out so all advised ranges are contiguous (or are a single data region), and issue one madvise over that whole region. Leave headers and indexes at normal readahead. Skip empty ranges.

Regression test: count lines in /proc/self/maps before and after N opens of a file with many segments, and assert the growth is O(1) per open (it went from +2000 to +2 for 4 opens of a 1003-segment file).

Related measurement tip: MADV_RANDOM on the data region removed up to ~15 MiB per cold request of 128 KiB readahead windows that the reader never used. Measure cold bytes per request, not just latency.