fix: make snapshot removal consistent

[shakkernerd]

Summary

• validate snapshot identity and managed archive paths before removal
• tombstone snapshot metadata before staging archive content out of live paths
• preserve post-removal cleanup warnings through direct removal, pruning, rollback, and environment destruction

Why

A linked recovery cleanup failure could occur after snapshot metadata and archive content were already removed. Callers could then report a safety snapshot as retained even though it was unavailable.

Verification

• AWS Crabbox: cargo test --locked
• AWS Crabbox: cargo check --locked --all-targets
• AWS Crabbox: cargo check --locked --target x86_64-pc-windows-gnu
• frozen OpenClaw 2026.6.11 through 2026.7.2 compatibility evidence remains applicable because runtime and version execution paths are unchanged

[shakkernerd]

Merged using rebase.

What changed after review:

• Reordered snapshot removal so metadata is tombstoned before archive staging, preventing a hard interruption from leaving a visible snapshot without its archive.
• Confirmed cleanup warnings propagate through direct removal, pruning, rollback recovery, and environment destruction.
• Confirmed corrupted snapshot identity and foreign archive paths fail before mutation.

Verification:

• Rebased/refreshed onto current origin/main before pushing.
• AWS Crabbox: cargo test --locked, cargo check --locked --all-targets, and cargo check --locked --target x86_64-pc-windows-gnu passed at the exact tested tree.
• Frozen OpenClaw 2026.6.11 through 2026.7.2 compatibility evidence remains applicable because runtime/version execution paths were unchanged.
• Auto-review: unavailable; equivalent exact-head calibrated review was clean.
• GitHub checks: Format, Rust 1.88 minimum, Windows compile, Ubuntu tests, and macOS tests passed.

Landed on main:

• Final landed SHA: a88a4b4; range 8a5c563...a88a4b4.

Thanks @shakkernerd!