Only unmap HVF sections that were mapped

[stevederico]

What changed and why

Refs #151. hvf_set_phys_mem() unmaps every removed section, and turns an add it cannot map into an unmap as well. When pflash leaves romd_mode on a write command, the flat view deletes its mapped ROMD section and adds an I/O section for the same range; that add becomes a second hv_vm_unmap() of the range, and deleting the I/O section on the way back to romd_mode is a third. #151's crash is EXC_GUARD (DEALLOC_GAP) in hv_vm_unmap, called from pflash_mem_write_with_attrs.

The ROM device's romd_mode already holds its new value when the old section is deleted, so the region cannot tell a mapped section from one that never was. The new QEMU patch macos/patches/qemu-hvf-mapped-sections.patch records the sections it maps (keyed by start address, since a section is removed with the range it was added with) and only unmaps what it recorded, like KVM's slot lookup. It applies after the free-page reclaim patch.

Testing

• python3 macos/Tests/test-hvf-mapped-sections.py: compiles the patched function against a fake HVF that refuses to unmap what it does not hold, and checks the mapping after every step of a pflash write/read cycle, device removal and an unaligned section. The original function makes four bad unmaps; the patched one makes none, and the flash traps while out of romd_mode
• The patch applies to QEMU c3d48b7 after all existing project patches
• make test passes on this branch on macOS 15.6 (MacBook Air, Apple Silicon)
• make runtime builds QEMU with this patch on macOS 15.6
• The crash was not reproduced (it was reported on an M4 with macOS 26.3), and the app was not run: a fresh guest can't be built right now (make guest fails: hyprland-guiutils 0.2.2-3 is gone from ALARM, and 0.2.2-4 needs hyprtoolkit 0.6 #280). An HVF trace from an affected M4 would confirm this is the path (see Add an opt-in HVF trace log to the launcher #278)