test: regexes over pinned and in-test input carry no wall-clock match timeout (#426)

[Blind-Striker]

The 11 test-side regexes that read pinned or in-test input no longer carry a wall-clock match timeout. A 1000 ms timeout there guarded nothing, and on a stalled macOS runner it failed three tests that match in microseconds.

Closes: #426. The same flake class at the tool-side sites, which this PR leaves out on purpose, is tracked in #427.

Root cause (measured, not assumed)

The macOS merge-group leg of #424 (run 39012584027) failed three UpstreamClientContractTests with RegexMatchTimeoutException in ParseRoutes. The first suspect was backtracking in RouteCall's lazy wildcards. Measurement rules that out. I timed the exact pattern, compiled and with the same options:

Input	Size	Routes	Whole parse	Worst single match
The failing tests' Client constant	1.1 KB	3	< 1 ms	< 0.01 ms
The same, 40 times	44 KB	120	0.3 ms	0.01 ms
Upstream's pinned client.ts	81.6 KB	129	0.3-1.3 ms	0.02 ms
The same, 40 times	3.26 MB	5,160	10.6 ms	0.04 ms

• The match is linear. All three failures parse the 1.1 KB constant.
• The failures were a stall. They landed within 0.4 s of each other (07:13:37.02 → .44). That is one runner stall across concurrently running tests. .NET's match timeout counts wall-clock time, so a thread descheduled for more than a second trips it with no regex work at all.
• So other fixes would not hold. Rewriting the pattern changes nothing, and a larger timeout only moves the threshold.

What changes

• The 11 sites: UpstreamClientContract's ten regexes and HandWrittenDoorRemarksTests' one use matchTimeoutMilliseconds: Timeout.Infinite. Each file carries the reason in one line: the input is the pinned upstream client, the repository's own remarks, or a test constant, never untrusted, and a wall-clock timeout only adds runner-load failures. The analyzer wall accepts it, with 0 warnings.
• A new row: Parse_Should_Read_The_First_And_Last_Route_Of_A_Client_Forty_Times_The_Pinned_Size parses a 3.3 MB client of 3,000 distinct route copies (about 40 times the pinned client). It reads the exact type of the first route and of the last. It holds the input-scale claim deterministically, rather than with a time limit.
  • It is not a red-then-green row. No input times out today, because the failure needs a stalled runner, so no deterministic test can reproduce it. The evidence for the fix is the measurement above.
• Not changed:
  • the tool-side sites and DriveManifestTests (Tool-side regexes over pinned input carry a 1000 ms wall-clock match timeout (same flake class as #426) #427), which are production tool code where a timeout is a separate decision;
  • the SDK's generated 100 ms key-regex timeout (protocol-and-generation.md ~:88), which runs over untrusted input at runtime.

Local check

At this head, on dev-01, after a root Release build: slopwatch 0 issues; the Release build with 0 warnings; both format passes; verify-clones passing; --help; generate --verify current; the whole Tools.Tests project (guards included) at 1996/0. Bun 1.4.3, off the 1.4.2 pin. CI is the full gate, including the macOS leg.

After merge: #424 re-enters the queue.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}