[MT] Consider spawning task host node in the very beginning, a soon as we know we are in the mt mode.

## Context

When MSBuild runs in multi-threaded (MT) mode, any non-enlightened task (SDK or custom) must be routed to a sidecar task host process. If no task host is pre-spawned, the first such task blocks the build while the task host process starts up. Measurements show task host process startup takes ~0.5 seconds on Windows, which is significant for small builds (e.g., `dotnet new console && dotnet build`).

## Problem

Until all SDK tasks are enlightened for MT, the very basic `dotnet new console` → `dotnet build` experience regresses in MT mode because the build blocks on task host startup at the first non-enlightened task invocation.

## Proposed Solution

As soon as MT mode is detected, eagerly spawn one task host process in the background so it is ready to accept requests by the time the first non-enlightened task needs it. Evaluation and other early build phases run in parallel with the task host startup, hiding the startup latency.

## Exit Criteria

- In MT mode, one task host node is spawned proactively at the start of the build.
- The `dotnet new console` → `dotnet build` scenario does not show a regression from task host startup in MT mode.

## Follow-Up

Once all SDK and MSBuild tasks are migrated to be MT-enlightened, re-evaluate whether this eager-spawn optimization is still needed. It may be removable if task host usage becomes rare.

## Notes

- Discussed in grooming on June 2, 2026.
- The ~0.5s startup cost includes process creation + JIT + initial node handshake.