OpenVMM CI: fix MSHV PCIe save/restore pulse hang #184

Context

#135 tracks enabling the remaining backend-native OpenVMM VMM tests. The MSHV PCIe save/restore case remains intermittently stuck during the pulse restore and cannot satisfy the ten-consecutive-pass gate.

Affected test

• multiarch::pcie::openvmm_linux_x64_pcie_save_restore

Evidence

On prometheus30 (linux-mshv, baremetal) at NVX fcce88654f8cdf4b8065c83c1336eaceca9e9304 / OpenVMM b9603efc025867a64a66db625fe6275f82a3753a:

1. The original test restored the four-root-port topology correctly, then could stall in pipette's guest-timer shutdown delay.
2. Replacing teardown with the enlightened shutdown IC removed that specific stall.
3. The resulting reliability sequence passed eight consecutive iterations.
4. Iteration 9 timed out at 600 seconds during the pulse before pipette reconnected.
5. OpenVMM completed the device start transition, but the guest did not open the offered hvsocket channel; time-sync messages continued while the test remained stuck.

This is distinct from the virtio Kick-backlog/stop-starvation fix in nanvix/openvmm#90.

Investigation areas

• MSHV synthetic timer and hvsocket/SynIC state after repeated pulse restore.
• Pending SINT message delivery and ObjectInUse results during restore.
• PCIe root-complex restore ordering versus partition resume and guest reconnect.
• A focused regression test that fails quickly instead of waiting for the global ten-minute Petri watchdog.

Acceptance criteria

• Root cause is fixed in OpenVMM or the MSHV integration layer rather than hidden by retries.
• The exact test passes ten consecutive iterations on MSHV bare metal.
• The required MSHV virtual-machine CI lane passes without runtime skips.
• Petri/OpenVMM logs retain enough state to diagnose future reconnect regressions.

Moved from #135.