fix(uninstall): report the caches it does not remove

[rominf]

Summary

rocm uninstall now names the caches it leaves behind, with their paths and why. Nothing new is deleted.

Please review:
  - the uv package cache is shared with other uv projects on this computer and is not removed: /home/<user>/.cache/uv
  - downloaded model files are slow to fetch again and may include your own, so they are not removed: /home/<user>/.cache/huggingface/hub

Root cause

build_uninstall_plan removes binaries plus the config, data, and cache directories. The two largest things an install causes to appear on disk are in neither:

• The uv package cache — uv_command_env() never set UV_CACHE_DIR, so uv used its own default outside the ROCm CLI directories.
• Downloaded model files — nothing in the product sets HF_HOME, so weights land in the shared default. hf_cache_roots_from only reads the environment for discovery.

A user who uninstalls to reclaim space can be left with tens of gigabytes still gone, with nothing in the output to suggest it.

Technical decisions

Report, don't delete. The uv cache is shared with every other uv project on the machine and ROCm CLI never claimed it; deleting it would slow down unrelated work. Model files are large, slow to re-fetch, sometimes gated behind a token, and may be the user's own. Naming them is what closes the honesty gap; deleting them is a separate decision.

Locations are resolved at run time from UV_CACHE_DIR, HF_HOME, and HUGGINGFACE_HUB_CACHE, falling back to the standard defaults — rather than assuming a fixed path.

Anything already inside a directory being removed is skipped, so a note is never printed for a cache that uninstall does in fact delete. This matters because #170 moves the uv cache under the data directory: once that lands, the uv note correctly stops appearing without further changes here, and it keeps working for users who point UV_CACHE_DIR elsewhere. The two PRs are independent and can land in either order.

Missing paths are not mentioned, so the output stays quiet on a machine that never populated them.

Tests

The filtering logic is split into a pure shared_cache_notes_for, so the three tests do not depend on the caller's real environment:

• a cache inside a removed directory is not reported (the note would be false)
• a cache outside everything being removed is reported, with its path
• a missing path is not mentioned

CI note

cargo test --workspace shows two unrelated failures in proc_lifecycle — see #168, fixed by #169. Everything else passes; fmt and clippy -D warnings are clean.

Fixes #163