Closes #757.

Summary

• Old _delete_inventory deleted inventory groups in place; a mid-run failure (perm denied, transient FS error, antivirus) left the user with a half-gone state dir (config + memories wiped, DB + runtime files surviving) and no practical recovery path.
• This PR makes the wipe transactional via a stage-then-rmtree pattern: every to-be-deleted path is moved via os.replace into a sibling <anchor>/.uninstall-staging-<pid>/ dir (atomic on same-FS), and only after every group is staged do we shutil.rmtree the staging dirs to actually delete the data.
• Mid-stage failures roll back: walk staged moves in reverse and os.replace each back to its original location. If rollback itself fails, the staging dir paths are surfaced so the user can recover manually (the original concern from the issue's "rollback granularity" question).
• Whole-dir staging for owned subdirs (config.d, memories, uploads) — one rename per subdir instead of N, and removes the post-deletion empty-prune dance the old code needed for those paths.
• Cross-FS layouts (e.g. a bind mount inside ~/.memtomem/) can't satisfy os.replace's same-FS atomicity guarantee. Detected upfront via st_dev probe and refused with a clear message; late-detection on EXDEV from os.replace covers what the upfront probe misses (stat race, transient errors). Detect-and-refuse rather than copy+delete fallback — the whole point of staging is atomicity.
• --keep-config / --keep-data still exempt their respective groups from the plan, so kept paths are never moved into staging at all.

Acceptance criteria

• If any single group's deletion fails, the user's state directory is left in its original (pre-uninstall) state — no half-states (test_rollback_restores_original_state_on_mid_stage_failure).
• Existing --keep-config / --keep-data / partial-error coverage still passes (28 + 1 skipped before, 31 + 1 skipped after).
• New test induces a mid-staging failure and asserts the original state dir is intact.
• New test covers cross-FS detection via monkeypatched EXDEV (real cross-FS layouts are too environment-dependent for CI; same code path either way).
• New test for the rollback-itself-fails recovery surface so the user gets the staging dir path.

Out of scope

• Changing the deletion order or inventory grouping.
• Touching the Windows --force contract from Windows: contract for mm uninstall --force against a live writer is undefined #730 / fix(cli): refuse mm uninstall --force on Windows when writer is alive #756 — that decision stands; the upfront refusal still fires before staging would even start.
• External-integration teardown.

Test plan

• uv run ruff check + ruff format --check (clean)
• uv run mypy packages/memtomem/src/memtomem/cli/uninstall_cmd.py (clean)
• uv run pytest packages/memtomem/tests/test_uninstall_cmd.py -m "not ollama" — 31 passed, 1 skipped (Windows-only, as expected on macOS)
• uv run pytest packages/memtomem/tests/test_cli_*.py -m "not ollama" — 63 passed (no sibling regressions)
• Windows CI lane: existing test_force_refuses_on_windows_when_writer_alive still fires before staging (refusal precedes _delete_inventory); new tests are platform-agnostic (monkeypatch-based).

🤖 Generated with Claude Code