Follow-ups after local SDK acquisition migration

## Context

During the local SDK acquisition migration into the .NET Install Tool, we intentionally kept the main PR focused on the core path:

- `dotnet.acquire` supports local SDK acquisition via `{ mode: 'sdk' }` in .NET Install Tool 3.2.0+.
- Local SDKs use isolated per-install folders and `~sdk` install IDs.
- Status/uninstall support fully specified versions.
- Local SDKs participate in local auto-update.
- The standalone `vscode-dotnet-sdk` extension was removed.

The implementation plan tracked several reviewer-raised open edges that are safe to defer. This issue captures those follow-ups so the planning document does not need to stay in the PR branch.

## Follow-ups

### 1. Decide/package-json policy for SDK requests via `x-dotnet-acquire`

`JsonInstaller` forwards package.json acquisition requests to `dotnet.acquire`. Now that `{ mode: 'sdk' }` is valid, package.json can become a startup-time local SDK install path.

Recommended work:

- Decide whether `x-dotnet-acquire` should allow local SDK requests.
- Ensure `installType: 'global'` from the JSON path is rejected/logged clearly.
- Add `JsonInstaller` tests for an SDK request and a rejected global request.

### 2. Harden `dotnet.acquireGlobalSDK` mode handling

`dotnet.acquireGlobalSDK` defaults missing `mode` to `sdk`, but callers may pass a non-SDK mode. The runtime-vs-SDK boundary is now more important because local SDKs are supported through `dotnet.acquire`.

Recommended work:

- Either force `mode = 'sdk'` in `dotnet.acquireGlobalSDK`, or reject non-SDK modes with a clear error.
- Add command-level coverage for the chosen behavior.

### 3. Clarify or expand `dotnet.findPath` behavior for extension-managed local SDKs

The tool can now install a local SDK and report it via `dotnet.acquire` / `dotnet.acquireStatus`, but `dotnet.findPath` still skips extension-managed installs for SDK mode. That may surprise callers and LM tools.

Recommended work:

- Decide whether `findPath` should discover extension-managed local SDK installs.
- If yes, define SDK path-search semantics and update implementation/tests.
- If no, make the docs/tool messaging explicit that local SDKs are found through `acquire`/`acquireStatus`, not `findPath`.

### 4. Decide whether LM local uninstall tooling should include SDKs

The LM tool `uninstall_vscode_owned_dotnet_runtime` is explicitly runtime/aspnetcore-only. With local SDKs now managed by the extension, agents have no local-SDK uninstall tool and may misroute users toward system SDK uninstall.

Recommended work:

- Decide whether to extend the local uninstall LM tool to SDKs, or keep SDKs intentionally unavailable.
- Update the tool name/description and implementation/tests to match the decision.
- Coordinate this with the `findPath`/LM messaging follow-up above.

### 5. Clean up local update test fixture install IDs

The new SDK auto-update tests use real install IDs via `getInstallIdCustomArchitecture`, but some older `LocalInstallUpdateService.test.ts` helpers still synthesize IDs that do not match real runtime/global-SDK/local-SDK encoding.

Recommended work:

- Migrate existing helper/fixtures to `getInstallIdCustomArchitecture` where practical.
- Keep explicit tests for the asymmetric rule: local SDK gets `~sdk`; global SDK remains unmarked except for `-global`.

## Already handled in the migration PR

- `getAssumedInstallInfo` mode-precedence bug.
- Segment-count-first local SDK validator to avoid noisy parse telemetry.
- Fully specified status/uninstall exact-match behavior.
- `existingDotnetPath` no longer overrides local SDK acquisition.
- `acquireGlobalSDK` stamps `installType: 'global'` when omitted.

Start with JsonInstaller tests and the command-level coverage for dotnet.acquireGlobalSDK, then review dotnet.findPath and the local uninstall LM tool behavior. Inspect LocalInstallUpdateService.test.ts and getInstallIdCustomArchitecture for the fixture cleanup. Done means the policy decisions are implemented consistently, covered by tests, and reflected in tool messaging or documentation.

Written by the indexing model from the issue text.