`Queue Tests` build step performs redundant NuGet restore, adding significant overhead to CI

### Problem

The **Queue Tests** CI step invokes `build.sh`/`build.ps1` with the `-restore` flag, causing a full NuGet restore graph traversal on every CI leg — even though the **Build** step immediately preceding it already performed that restore. While most projects come back as "up-to-date for restore," MSBuild still has to evaluate the entire project graph to determine this, burning several minutes of wall-clock time.

### Evidence

From [build 1529392](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1529392&view=results) (batched CI trigger, 2026-07-28):

| Leg | Build duration | Queue Tests duration | Restore phase in Queue Tests | Restore % of Queue Tests |
|---|---|---|---|---|
| Linux x64 | 10m 19s | 6m 54s | ~3m 20s | **~48%** |
| Windows x64 | 14m 53s | 7m 37s | ~4m 07s | **~55%** |
| Mac x64 | 18m 39s | 15m 39s | ~10m 05s | **~65%** |
| Mac arm64 | 28m 43s | 16m 58s | ~10m 47s | **~64%** |

The Build step already ran `-restore -build`, leaving NuGet assets fully up-to-date. The Queue Tests step re-evaluates the full dependency graph from scratch anyway, producing output like:

```
Determining projects to restore...
8 of 17 projects are up-to-date for restore.
...
All projects are up-to-date for restore.
```

### Expected Outcome

The Queue Tests step should complete significantly faster. Based on the data above, eliminating the redundant restore work should save **~3–11 minutes per leg**, with macOS legs benefiting the most.

### Impact

Every CI run that queues Helix tests is affected, making this a broad and recurring source of wasted build time across all platforms.