`dotnetup`: Make tests localization-safe

### Prerequisites

- [x] I have read the [dotnetup documentation](https://github.com/dotnet/sdk/tree/release/dnup/documentation/general/dotnetup).
- [x] I have searched for [existing dotnetup issues](https://github.com/dotnet/sdk/issues?q=is%3Aissue%20state%3Aopen%20label%3Adotnetup).
- [x] I have searched for [existing dotnetup discussions](https://github.com/dotnet/sdk/discussions/categories/dotnetup).

### Issue type

Bug report

### Description

## Description

`EnvDriftAnalyzer` returns localized strings from `Strings.resx`, but `EnvDriftAnalyzerTests` introduced in https://github.com/dotnet/sdk/pull/54545 verifies those results using English sentence fragments such as:

- `"missing the dotnetup managed block"`
- `"contains a dotnetup managed block"`
- `"'everywhere' mode expectations"`
- `"missing from the user PATH"`

This was identified in [PR #54545 review feedback](https://github.com/dotnet/sdk/pull/54545#discussion_r3554259003). The [reply](https://github.com/dotnet/sdk/pull/54545#discussion_r3571986252) agreed that the tests can fail under another UI language but deferred changing them until tests are intentionally run under different languages.

The risk still exists: a translated XLF target can change the production result while the test continues to require English. A French-UI run passes today only because the newly added French resource targets still contain the English source text; that does not make the assertions localization-safe.

## Proposed change

Compare against the corresponding strongly typed `Strings` values instead of English fragments. For formatted messages, construct the expected value with the same invariant formatting contract used by production code.

Keep assertions focused on which drift condition is returned, rather than on a language-specific substring. Where a test only needs to distinguish one result, an exact resource-value comparison is preferable.

## Acceptance criteria

- `EnvDriftAnalyzerTests` contains no hard-coded English fragments from localizable drift messages.
- Tests compare exact resource values, including formatted resource values where applicable.
- The tests pass when `CurrentUICulture` or `DOTNET_CLI_UI_LANGUAGE` selects a translated supported language.
- Existing drift cases and Windows platform conditions retain equivalent coverage.

## Scope

Start with `EnvDriftAnalyzerTests`, which was the reviewed surface. If the same hard-coded-localized-output pattern exists in nearby dotnetup tests, include those only when the conversion is mechanical and directly related.

We should also investigate other tests in the `dotnetup` space and remove any others that have this pattern.

### dotnetup version

_No response_

Start with EnvDriftAnalyzerTests and compare its assertions with the strongly typed Strings values used by EnvDriftAnalyzer. Replace hard-coded English fragments with exact or formatted resource-value comparisons, then run the tests with CurrentUICulture or DOTNET_CLI_UI_LANGUAGE set to a supported translated language. Done means existing drift and Windows-specific coverage remains equivalent and no hard-coded localized-output fragments remain.

Written by the indexing model from the issue text.