Audit remaining snapshot/restore failure paths for app.log coverage

Follow-up to #1248 and #1250. #1248 improved failure logging for snapshot restore (shared restore-failure helper, dedup of failure logging, containment of repair-pass rejections as repair errors), but the fix was scoped to the restore path.

Remaining work: audit the other snapshot and env-management codepaths for #1250-style gaps where errors surface in the UI (or are swallowed) without being recorded in the install''s app.log:

- snapshot capture/export/import/staging paths
- torch stack switching (`change-pytorch`) failure paths
- create-install-from-snapshot fallback paths (including the pruned-R2-bundle fallback added in #1248)
- migration/adoption scanner errors

Each user-visible failure should leave enough evidence in app.log to diagnose without asking the user to reproduce.

Read issues #1248 and #1250 first to understand the existing restore-failure logging changes. Audit the snapshot capture/export/import/staging paths, torch stack switching, create-install-from-snapshot fallbacks, and migration/adoption scanner for failures shown or swallowed without app.log entries. Done means each user-visible failure leaves enough diagnostic evidence in the install's app.log.

Written by the indexing model from the issue text.