runtime_install_root_is_protected is a denylist, not an allowlist

Problem

runtime_install_root_is_protected (crates/rocm-core/src/runtime.rs) decides whether a runtime folder sits somewhere too dangerous to delete by enumerating known-bad locations. That means anything it has not thought of is treated as safe. It returns false for $HOME exactly, and for /home, /mnt, /srv and /media; the Windows branch hardcodes C:, so another drive letter is unprotected.

Nothing reaches those gaps today: deletion additionally requires a matching in-tree .rocm-cli-runtime.json whose runtime_key, runtime_id and install_root all agree, which a copied or moved tree does not satisfy. So this is a defence-in-depth guard rather than a live bug.

Why it matters now

rocm storage remove-old-installs (#172) leans on this guard for a set of folders the user never typed out, which is a different risk profile from rocm runtimes uninstall naming one. Belt-and-braces guards are worth having actually hold.

Suggested direction

Invert it: require the folder to be under a known ROCm CLI data root (or otherwise positively established as ours) rather than merely not matching a list of bad places. Platform-independent handling for Windows drive roots too.

Context

Out of scope for #172. Raised from review feedback on that PR.

Start in crates/rocm-core/src/runtime.rs and trace how runtime_install_root_is_protected is used by rocm storage remove-old-installs. Establish the known ROCm CLI data roots and review the Windows handling, then verify that only positively established locations are protected from deletion, including roots on drives other than C:.