runtimes: the Windows protected-root list omits the drive root, C:/Users and C:/ProgramData

[rominf]

Current behavior

On Windows, runtime_install_root_is_protected checks a three-entry list:

C:/Windows, C:/Program Files, C:/Program Files (x86)

Consequences:

• It never reaches the "is this the filesystem root?" check that the Unix branch has, so a drive root is not in the protected set. (ensure_runtime_install_root_is_safe_to_remove should still refuse C:\ via its parent().is_none() pre-check, but that pre-check is the only thing standing there.)
• C:/Users and C:/ProgramData are absent.
• The drive letter is hardcoded to C:, so Windows installed on another drive is unprotected.
• The folder names are hardcoded in English, so a localized install is unprotected.

For comparison, the Unix branch protects 13 roots plus /.

Expected behavior

The Windows list should cover the equivalent ground to the Unix one, and should not depend on a hardcoded drive letter or on English folder names. The platform's own APIs (e.g. SHGetKnownFolderPath) report these locations.

Additional context

This is an incomplete policy rather than a broken comparison, which is why it was left out of #491.

It is worth filing now because #491 changes its practical exposure in both directions. Direct respellings (C:/Windows/, c:/windows, C:/Windows//System32) are now correctly caught. Conversely C:\Windows\..\ProgramData was previously refused only because the old text-based ancestor walk matched C:\Windows as a literal ancestor; it now correctly resolves to C:/ProgramData and is accepted, because that path genuinely is not on the list. In other words, the narrow list was partly masked by the bug that #491 fixed.

Note also that the branch selecting this list still reads the platform at runtime, so it is only reachable on the Windows CI lane — Linux-only clippy never sees it.