Snapshot restore: retry UX for recoverable restore failures on bootable installs

Follow-up to #1248 and #1255. After #1248, a restore failure no longer necessarily leaves the install "unbootable" — the failure is contained, logged, and a post-restore snapshot of the actual resulting state is written where applicable.

However, when a restore fails partway on an otherwise bootable install, the user currently has no guided way to retry:

- Offer a "Retry restore" action on the failure surface (and/or on the snapshot row) that re-runs the same restore with the same mode.
- Distinguish recoverable failures (network blip during pip download, transient git failure) from non-recoverable ones (snapshot references a torch stack that cannot exist on this hardware) and only offer retry for the former.
- Consider offering "retry in compatible mode" when an exact restore fails for stack-availability reasons.

Start by reading the context in issues #1248 and #1255, then trace the existing restore failure surface and snapshot row behavior. Define how recoverable and non-recoverable failures are identified, how the same-mode retry is represented, and whether compatible-mode retry is feasible. Done means recoverable failures offer a guided retry without compromising the bootable install, while unsupported stack failures do not.

Written by the indexing model from the issue text.