Fix warm fork guest MAC reconfiguration

[sjmiller609]

Summary

• apply the allocated MAC during post-restore guest network reconfiguration
• verify eth0 reports the expected MAC before restore readiness succeeds
• cover the generated reconfiguration command in unit tests

Testing

• go test ./lib/instances -run 'Test(GuestNetworkReconfigureCommand|NetworkConfigFromAllocation|RequiresRestoreConfigDiskRefresh)'\n- go test ./lib/instances ./lib/hypervisor/firecracker

---

Note

Medium Risk
Changes standby-restore guest networking and MAC allocation; misconfiguration could break fork connectivity or cause MAC clashes, but scope is narrow and covered by new unit tests.

Overview
Warm standby fork restores now rebuild guest eth0 identity to match the new allocation, not only the snapshotted IP/route.

Post-resume guest network setup is centralized in guestNetworkReconfigureCommand, which validates IP/MAC/gateway/netmask, brings eth0 down, sets the allocated MAC, flushes old IPv4 addresses, reapplies the fork IP and default route, brings the link up, and flushes neighbor cache. CreateAllocation now picks MACs unused across existing allocations (random retries, then sequential scan in the 02:00:00:… space), with unit tests for collision handling and the generated shell command.

^{Reviewed by Cursor Bugbot for commit c4aba89. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Firetiger deploy monitoring skipped

This PR didn't match the auto-monitor filter configured on your GitHub connection:

Any PR that changes the kernel API. Monitor changes to API endpoints (packages/api/cmd/api/) and Temporal workflows (packages/api/lib/temporal) in the kernel repo

Reason: PR modifies guest MAC reconfiguration logic in instances/hypervisor packages, not the API endpoints or Temporal workflows specified in the filter.

To monitor this PR anyway, reply with @firetiger monitor this.