fix(shell): harden PowerShell host probe against cold-start timeouts

[Aaronontheweb]

Problem

Windows CI flake: TestShellEnvironment's static ctor resolves the shell environment by probing pwsh.exe with a hard 5s timeout. On a loaded Windows runner the cold pwsh.exe spawn (Defender scan, first-run init) exceeded 5s, the resolver threw (Failed did not fall back), and every dependent test class died with TypeInitializationException — 123 tests in run 31417450377.

The same risk exists in production: daemon startup resolves the shell env (Program.cs:133), so a slow pwsh could brick startup.

Changes

1. Probe retries once on timeout. PowerShellHostProbe.ProbeAsync retries (250ms backoff) when the only failure is Timeout; other failures return immediately. Each attempt spawns a fresh process. Worst-case probe latency doubles (~12.5s per executable) but only on the rare timeout path — healthy hosts see zero added latency.

2. Probe failure is fallback-eligible. The resolver no longer hard-throws when the pwsh probe fails. It probes powershell.exe 5.1 and records PowerShellFallbackReason.PreferredHostProbeFailed (startup logs a warning). Both-fail still throws — fail-closed is preserved, and the combined message now lists both failures (the old early-throw hid the preferred-failure detail).

3. CI warm-up. pr_validation.yml pre-warms the probe on Windows runners (both pwsh and the powershell.exe fallback) so cold-start cost doesn't eat the in-test timeout budget.

Tests

• Resolver test updated: pwsh probe Failed now selects Windows PowerShell 5.1 with PreferredHostProbeFailed; new both-fail test asserts the combined error.
• Probe retry tests (fake-time driven): timeout→retry→recover, timeout→timeout returns Failed(Timeout), non-timeout failure does not retry.
• Full Netclaw.Daemon.Tests: 1000/1000 pass on Linux.
• Windows CI on this PR is the definitive check.

Note

Worst-case Windows daemon startup when both hosts are slow is now ~25s before failing with a clear combined error (vs ~6s before). Intentional tradeoff: slow-but-successful, or slow-but-clear failure, instead of bricked startup on a transient cold-start timeout.