dotnetup: Clarify untracked install behavior in manifest-tracked roots

## Context

PR [#53464](https://github.com/dotnet/sdk/pull/53464) review raised questions about whether untracked installs should be allowed in dotnet roots that are tracked by a manifest.

### Related PR Comment

- [DotnetupSharedManifest.cs L331](https://github.com/dotnet/sdk/pull/53464#discussion_r3040115414) — @dsplaisted: "Should we / do we allow untracked installs in a dotnet root that is tracked by a manifest? I think the scenario for untracked is for folders that aren't in the manifest at all."
- @nagilson: "I'm ok with this for now but this is worth revisiting when we expand / flesh out the manifest supporting in existing folders, let's track this in an issue."

## Description

The `--untracked` flag allows installing into a location without recording it in the dotnetup manifest. The question is whether this should be permitted in a root that already has a manifest — doing so means:

- The manifest won't reflect all installs in that root
- `dotnetup list` won't show the untracked install
- GC/prune operations may not account for it
- Future manifest operations might conflict

## Acceptance Criteria

- [ ] Decide on the intended behavior: should `--untracked` be blocked when a manifest exists, or is it intentionally allowed?
- [ ] If blocked: add validation and a clear error message
- [ ] If allowed: document the behavior and its implications
- [ ] Add tests for the chosen behavior
- [ ] Update help text for `--untracked` to clarify scope

## Relevant Code

- `src/Installer/dotnetup/DotnetupSharedManifest.cs` (L331)