Tool-side regexes over pinned input carry a 1000 ms wall-clock match timeout (same flake class as #426) #427

The same flake class as #426, at the sites #426's fix leaves out on purpose.

Finding

.NET's regex match timeout is wall-clock: a thread descheduled on a stalled CI runner trips it with no matching work at all. #426 showed this on a macOS merge-group leg. Three UpstreamClientContractTests failed within 0.4 s of each other over a 1.1 KB constant that matches in microseconds, which ejected an unrelated PR (#424). The fix for #426 removes the timeout from the 11 test-side regexes over pinned and in-test input.

These sites carry the same 1000 ms wall-clock timeout over trusted, repository-pinned input, and they also run in the test suite:

Why it is not in #426's fix

The tools regexes are production tool code. Whether a timeout stays there as defence in depth, sized to the input with its reason, or goes because the input is pinned, is a decision for the tool, not for a test fix. DriveManifestTests uses a plain static Regex for its net472 leg (.editorconfig ~:1130), so its shape differs.

Out of scope: the SDK's generated 100 ms key-regex timeout (protocol-and-generation.md ~:88) runs over untrusted input at runtime, and it stays.

Priority

This belongs in the U7 sweep. A real CI ejection from any of these sites moves it to the front.