[WSL2][Onboard] running Windows-hosted Ollama is shown only as an install option

## Description

On NemoClaw v0.0.121 in WSL2, a healthy Windows-hosted Ollama daemon is reachable from WSL and exposes an installed model, but the interactive onboarding provider menu does not identify it as a running local provider. The menu offers only Windows-host and WSL installation choices, and the equivalent non-interactive Windows-Ollama path aborts instead of reusing the running daemon.

Platform scope: Reproduced on WSL2 x86_64; WSL2 arm64 and non-WSL platforms were not tested for this exact discovery flow.

Regression: Unknown — earlier versions were not tested with this exact discovery flow.

OpenShell issue: No.

This is distinct from #8127: the Windows-hosted Ollama API is reachable from WSL in this reproduction; the failure is provider discovery and reuse rather than endpoint validation after selection.

## Environment

```text
Device: Windows PC running WSL2
OS: Windows 11 / WSL2 Ubuntu 24.04
Architecture: x86_64
Node.js: v22.23.1
npm: 10.9.8
Docker: Docker Desktop
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.121
Agent: Hermes
Provider: Windows-hosted Ollama
```

## Steps to Reproduce

1. Start Ollama on the Windows host with its API listening on port 11434 and at least one model installed.
2. From WSL2, verify that `http://host.docker.internal:11434/api/tags` returns HTTP 200 and lists the model.
3. Confirm no WSL-native Ollama binary, service, process, or listener is present.
4. Run `nemoclaw onboard` and proceed to the inference-provider menu.
5. Inspect the local Ollama choices.
6. Optionally run non-interactive onboarding with the Windows-host Ollama provider selected.

## Expected Result

The provider menu displays the reachable Windows-hosted Ollama daemon as running and reusable. Selecting it, interactively or non-interactively, reuses the existing daemon without installing Ollama in WSL or replacing the Windows process.

## Actual Result

The provider menu does not show a running local Ollama provider. It offers only:

```text
Install Ollama on Windows host (loopback only)
Install Ollama (WSL Linux)
```

The equivalent non-interactive Windows-host path reports that it cannot inspect the existing Windows Ollama state and exits without creating the sandbox, even though the API is reachable and the Windows Ollama process remains running.

## Logs

```text
GET http://host.docker.internal:11434/api/tags -> HTTP 200 with an installed model
Select your inference provider:
Install Ollama on Windows host (loopback only)
Install Ollama (WSL Linux)
Could not capture the existing Windows Ollama state; leaving it unchanged.
NemoClaw could not inspect the existing Windows Ollama state.
```

## Accepted implementation plan

- Decision: Accept the remaining full-flow verification slice. Merged PR #11631 already owns the known source fix.
- Reason: Current source and focused tests implement the reported behavior. The remaining gap is composed Windows 11, WSL2, Docker Desktop, PowerShell, and Ollama evidence.
- Placement: No source change is authorized until full-flow UAT identifies a remaining defect.
- Accountable maintainer: @rsliter. Existing assignee @ericksoa remains assigned.
- Capability slice: Run interactive and non-interactive onboarding against an existing Windows-hosted Ollama daemon. Verify sandbox creation and one agent turn without changing daemon PID, start time, User-scope `OLLAMA_HOST`, or model inventory.
- Acceptance evidence: Bind the UAT receipt to exact NemoClaw, Windows, WSL, Docker Desktop, and Ollama versions. Record sandbox cleanup.
- Validation plan: Run focused provider discovery, menu, selection, Windows state, rollback, and transport tests before the real two-arm journey.
- Deferred scope: A permanent Windows CI lane, WSL2 arm64, native Docker-in-WSL, and Windows Ollama installation qualification.
- Stop conditions: Close the issue if both journeys pass. If either fails, preserve redacted phase-specific evidence and plan only the observed defect. Do not open a speculative implementation PR.