VmGroup: pool forks of one master into a shared struct kvm

I've been running a KVM_CREATE_VM-elimination line on the fast-agent branch and want to upstream it.

Problem: at high fork churn, per-fork VM create/destroy dominates, each KVM_CREATE_VM pays mm_take_all_locks plus a PM-notifier registration on a global rwsem whose chain walk is O(live VMs). Mass termination and warm-fill decay measurably past ~10k live VMs.

A VmGroup owns one KVM VM and hands out seats (vcpu fd, kvm_run mapping, POSIX timer, arena GPA partition in one MAP_NORESERVE window) to pooled forks of one master. One KVM_CREATE_VM per B forks instead of per fork; zero memslot ops and zero mmaps in a live group's steady state; host VMAs flat at ~10k out to 100k members. Feature-gated (MachineOptions::vm_group), default off; the whole suite also passes with it forced on. Pooled members refuse remote/IPRE, SMP, hugepages, reset_to_new_master, foreign-range deletes.

11 commits, rebased onto current master. Proposed ladder:

1. KVM_RUN failure classification by whether the timeout timer fired
2. lazy per-fork kvm_run mapping + cpu_id → kvm_vcpu_id/guest_cpu_index split
3. VmGroup core, x86-64 (4 commits: pooling, lifecycle/PTE-partition invariant, one host mapping per group, one memslot per group)
4. ARM64 port (3 commits; the PTE-partition invariant stays AMD64-only)

One PR each, 3 before 4. Object here if the seats-in-one-struct-kvm direction is wrong before we open them.

Start by reviewing the fast-agent branch and the 11 commits, beginning with KVM_RUN failure classification and the lazy kvm_run mapping work. Then examine the proposed x86-64 and ARM64 VmGroup ladder, including the seat, lifecycle, PTE-partition, host-mapping, and memslot invariants; done means deciding whether the shared-struct-kvm direction is suitable before separate PRs are opened.