[mtalvi]

A documented make saw-restart previously called virtctl restart. Both original VMs and a fresh control were force-terminated after the implicit 30-second grace. Raising grace to 180 seconds alone was insufficient: both controls again expired and were marked Destroyed. Guest journals show shutdown reached filesystem unmounting; the exact blocked component remains unidentified. Guest-initiated poweroff completed naturally on both controls, with filesystem sync/unmount and console power-down evidence.

Change saw-restart and confirmed saw-restart-pending to use the existing guest SSH path for sudo systemctl poweroff. Require runStrategy: Always, wait for a different Running VMI with the updated mounted inputs, and report boot install/apply as a separate step. Guest access failure returns an error without falling back to host termination. Existing disks and sandbox volumes remain in place.

Also set a configurable 180-second VMI termination grace. This gives other termination paths more time; it is not a demonstrated fix for the host-triggered shutdown stall. The supported restart path adopts the updated template for existing VM instances.

Refs #161 and the release gate in #157. Credential persistence is corrected separately in #162; the public interceptor pin stays in #160. The original damaged Podman catalog remains preserved, with cause/onset unproven. No database repair, package upgrade or journal-mode change is included.

Validation:

• 22 focused tests passed, covering guest-poweroff/replacement sequencing, missing and starting instances, refusal before mutation for non-Always/nonrunning VMs, guest-command failure without host fallback, SSH access and bulk dispatch.
• Repository chart and rendered-shell lint passed. Earlier chart default/override suite: 128 passed, with no subsequent chart-template changes.
• All six CI checks pass at final head 8001cc7c6454bf5398a6ea83065174af0c087a06, including Python 3.12 and 3.14.
• The actual documented make saw-restart passed on both existing controls from combined deployment 0abf643dcd0de422bd69b91404ef373e8a1d5827. C naturally powered down at 14:52:34 UTC, D at 14:52:38 UTC on November 12. Both consoles confirm filesystem sync, all filesystems unmounted and power down; virt-handler reports Shutoff reason Shutdown. Neither grace expiry nor Destroyed occurred. Different Running VMIs were observed, both grace180.
• Consistent SQLite snapshots immediately before restart were ok. Existing disks/volumes were preserved, with no package/database/journal-mode changes. Obsolete old-code install/reconcile work was stopped before the test without persistently disabling units; the replacements run normal boot install/apply.

The supported operator restart path is validated and ready for review. Boot apply/inference acceptance for the separate credential correction remains tracked in #161/#162 and the #160 release gate. The generic host-triggered shutdown stall and original catalog damage's cause remain unresolved; this PR does not claim to fix those other termination paths. Nothing has been merged.

Further combined-source documented restarts also completed naturally at15:21:31 UTC (C) and15:22:16 (D), with powerdown/unmount evidence and no expiry/Destroyed. The restart correction does not establish data preservation: #165 separately records the existing installer automatically replacing D’s CUDA workspace after an earlier boot. #160 rollout remains held for that data-preservation fix; it is being handed off at the operator’s request.