netresize: eject timeout leaves record/live NIC state diverged and unretryable

[CMGS]

Pre-existing (present on master before PR #101; confirmed by line-level review of both branches) — filed from the PR #101 dual-channel review round.

Problem

netResizeRemove (hypervisor/cloudhypervisor/netresize.go) calls removeDeviceVM then waitDeviceEjected; on eject timeout it returns before truncateNetworkConfigs, so:

• live CH state: NIC removed (or removed moments after the 30s window — Windows guests can be slow)
• cocoon record: still carries the NIC (NetworkConfigs length N)

A retry of vm net --nics <target> then fails permanently: macToID is built from live vm.info, the removed NIC's MAC has no live device, and the loop errors with nic %d MAC %s: no live device — the divergence is unrecoverable from the CLI.

Trigger requires a guest that takes >30s (ejectWaitTimeout) to ack B0EJ for a NIC; normal guests ack in <1–20s, so this is rare.

Suggested directions (either)

1. On eject timeout, log/flag the divergence the same way the persist-failure path already does (persistence diverged from CH for vm ... live device removed, cocoon record retained, netresize.go:120) so the operator sees the state, and/or
2. Make the retry path reconcile: when a recorded NIC's MAC has no live device, treat it as already-removed and truncate the record instead of erroring.

Non-goals

Not a PR #101 regression — the ordering predates that branch; the disk/fs/vfio detach path got a blocking waitDeviceEjected in PR #101 and is not affected by this issue.

[hiSandog]

The fix would be easier to review if it came with a narrow test for netresize: eject timeout leaves record/live NIC state diverged and unretryable. I would assert both the current failure mode and the intended successful behavior, especially around netResizeRemove.