HV: implement virtio-balloon device registration

[AprilNEA]

Problem

initialize_darwin_hv() in virt/arcbox-vmm/src/vmm/darwin_hv/mod.rs registers console, VirtioFS, block, net, rng, and vsock — but not virtio-balloon. The VZ path registers balloon at virt/arcbox-vmm/src/vmm/darwin.rs:139-143.

Impact

Host memory reclaim under pressure is unavailable on the default backend. When the host runs low on RAM, the VM cannot release unused guest pages back — the entire guest RAM region stays pinned. Matters for idle background VMs and multi-VM scenarios.

The project's Custom VMM roadmap (internal-docs/plans/custom-vmm-roadmap.md) classifies this as "nice-to-have, not blocking for M2" — but it is blocking for full VZ parity and should be in place before VZ is deleted.

Scope

1. Add a arcbox-virtio-balloon implementation (or confirm one already exists in the shared virtio crate stack and is just not wired).
2. Register it in initialize_darwin_hv() alongside the other devices.
3. Wire feature negotiation: VIRTIO_BALLOON_F_DEFLATE_ON_OOM, VIRTIO_BALLOON_F_REPORTING if we want page reporting.
4. On the host side: expose a target-size API so the daemon can signal "reclaim N pages".
5. Integration test: inflate balloon, verify guest RSS drops; deflate, verify it recovers.

Not in scope

• Free page hinting (separate feature, needs guest kernel support).
• Automatic balloon sizing under macOS memory pressure (follow-up).

Acceptance

• Balloon device registered and negotiated in HV-backed VMs.
• Manual inflate / deflate round-trip works end-to-end.
• Unit + integration tests pass.

[linear]

ABX-363