Keep mremap growth out of occupied suffixes

[Ksld154]

Problem

Adjacent anonymous mappings can coalesce into a tracked region that extends
beyond the source range passed to mremap. The in-place growth check skipped
that region when its start matched the source address, so it treated the live
suffix as free and cleared its contents.

Linux permits in-place growth only when the source range ends at the end of
its VMA. An occupied suffix must make a request without MREMAP_MAYMOVE fail
with ENOMEM; with the flag, only the source range may relocate.

This bug caused Alpine apk to crash while resolving packages from local
repository indexes.

Regression coverage

• Two separately mapped adjacent anonymous pages reproduce the coalesced-region
  case that exposed the bug.
• One two-page anonymous mapping exercises the occupied-suffix path by
  construction, independent of region-merging policy.

Both cases verify that a request without MREMAP_MAYMOVE returns ENOMEM
without changing either page. They also verify that MREMAP_MAYMOVE relocates
the source data, zeroes the new extension, and preserves the occupied suffix.

Environment

• macOS 26.7, Darwin 25.6.0
• Apple Silicon arm64
• Apple SDK 27.0
• Alpine 3.21 aarch64 guest

Validation

• make check-format: passed
• build/elfuse build/test-mremap: 14 passed
• bash tests/test-matrix.sh all: the QEMU aarch64 lane passed 271 tests with
  no failures; the elfuse aarch64 lane passed 292 tests, with the unrelated
  test-dup-setfl-race timing out under the full matrix load and passing when
  run alone; Rosetta-independent x86_64 guardrails passed
• Alpine apk --no-network --simulate add git: three consecutive runs exited
  with status 0
• make check: all 99 core tests and all mremap suites passed; the final
  BusyBox nslookup smoke test could not reach a DNS server
• make verify: not completed because Frama-C is unavailable locally

Closes #389

---

Summary by cubic

Protects adjacent coalesced mappings from being overwritten during in-place mremap growth. Previously, growth could zero live bytes in a neighboring mapping when the region extended past the source range; now it returns ENOMEM without MREMAP_MAYMOVE and relocates with MREMAP_MAYMOVE, preserving both mappings.

• Adds a regression test covering both growth modes and verifying contents are preserved.

^{Written for commit 1836227. Summary will update on new commits.}

[jserv]

Refusing in-place growth here sends a source whose region extends past grow_off down the move path, which is right, and it removes the old path's worst case: a memset of grow_len zeros straight into a live MAP_SHARED file overlay, which wrote those zeros to the backing file.

One hole survives the move. cleanup_overlays_in_range rounds its teardown up to the host page (ALIGN_UP(end, hps), 16 KiB on Apple Silicon) while guest ranges are 4 KiB granular, and hvf_restore_slab_backing re-mmaps fresh slab without repopulating from the file, so growing the first 4 KiB of a shared file mapping leaves the next 12 KiB of the surviving suffix reading slab instead of file contents. That was already reachable through a separate mapping at grow_off, so it is a follow-up rather than something this change owes.

[Ksld154]

Agreed. The 16 KiB overlay teardown is independent of this change and remains reachable through a separate mapping at grow_off. It needs a separate issue and regression test. Will take time to reproduce the follow-up and open a new issue.

[jserv]

Check https://github.com/sysprog21/elfuse/blob/main/CONTRIBUTING.md carefully.

[jserv]

Thank @Ksld154 for contributing!