Improved work scheduling algorithms to increase parallelism

Potential approaches for increasing build parallelism and improving work scheduling efficiency in MSBuild.

## Current Scheduler Behavior
Build requests associated with a specific configuration are always routed to the same worker node for that configuration. Never-before-seen configurations are assigned to the first available node.

When a subsequent request needs to run new targets in that configuration, it is blocked on the availability of that node, which may be building another request/project. This can serialize requests that could have built concurrently if they had been scheduled to different nodes.

## Experimentation Areas
### 1. Explore Alternative Scheduling Models

Potential experiments include:

Assigning each configuration to its own thread-backed worker.
Increasing the number of worker nodes significantly beyond the current defaults.
Comparing these approaches against the current scheduling strategy to better understand scaling characteristics and bottlenecks.

The goal is not necessarily to adopt these models directly, but to establish performance baselines and identify areas where scheduling decisions limit parallelism.

### 2. Leverage Historical Build Graph Information

A promising direction is to persist project dependency graph information from previous builds and use that information to make better scheduling decisions in subsequent builds.

Possible benefits include:

Reducing accidental serialization caused by uninformed node assignment.
Scheduling work based on known dependency relationships.
Achieving some graph-build characteristics even for non-graph builds after the first build.
Improving critical-path utilization.

An existing prototype already exists that stores build plan information externally. A low-cost experiment would be to adapt that mechanism to use server-resident state instead of file-based persistence. That's #11673.

### 3. Improve Node Affinity and Cache Reuse

The discussion highlighted opportunities to bias scheduling decisions based on previous executions:

Assign projects to the same node as in previous builds when beneficial.
Improve cache reuse and reduce repeated initialization costs.
Balance affinity benefits against the need to keep idle workers busy.

### 4. Reduce Scheduling-Induced Blocking

Several examples were discussed where work could be delayed due to current scheduling choices rather than true dependency constraints.

Areas of interest include:

Better utilization of available workers.
Reducing unnecessary waits for node availability.
Using dependency information to avoid delaying work on the critical path.
Constraints and Considerations

## Any scheduling changes need to account for:

- Worker startup and management costs.
- Oversubscription of CPU and memory resources.
- The need to limit concurrent work even if scheduling becomes more aggressive.
- Tradeoffs between locality/cache reuse and immediate execution opportunities.

## Proposed Next Steps
- Time-box several low-cost experiments.
- Collect data for alternative worker allocation strategies.
- Evaluate reuse of historical build graph information in the server process.
- Use experimental results to estimate the practical performance ceiling before making larger product investments.

Start by reviewing MSBuild's current scheduler behavior and the historical build-plan prototype referenced in issue #11673. Compare worker-allocation and server-resident graph-information experiments while measuring parallelism, blocking, resource limits, and cache reuse. Done means producing experimental data and a recommendation for future scheduling work.

Written by the indexing model from the issue text.