fix: address three remaining flakes from CI Stress run #25511463854 (#196)

After PR #193 dropped the per-shard failure rate from 32% to 7.5%,
three flakes remained. Investigation produced one production fix,
one fixture-side race fix, and a more honest test of the render
coalescing invariant.

Validation regex timeout — production fix
─────────────────────────────────────────
ValidationIntegrationTests.Full_Pipeline_Valid_State failed because
Validate.Email's MatchValidator capped regex execution at 200ms wall
clock. Under threadpool starvation on a CI runner, the timer that
RegexMatchTimeout uses can fire mid-match even though CPU time was
microseconds, causing IsMatch to throw RegexMatchTimeoutException
and the validator to mark the legitimate "user@example.com" as
INVALID. Bump validator regex timeout to 1s. Diagnostic-path
timeouts (DevtoolsPropertyTools, LogCaptureBuffer, DevtoolsUiaTools)
keep their 200ms caps — they're admin/dev-only, not on the
keystroke path. False-invalid validation on legitimate input is
worse UX than slower tarpit detection on adversarial input, since
the former affects every user under any CI-loaded environment.

AsyncResource.Framerate.DepsThrashing — fixture race fix
─────────────────────────────────────────────────────────
DepsThrashing_AtMostOneCompleted asserted completed<=1; observed
completed=2. The fetcher's race window: `await Task.Delay(200, ct)`
followed unconditionally by `Interlocked.Increment(ref completed)`.
When deps change exactly as the 200ms timer fires, Task.Delay's
internal atomic result-set can be won by the timer before
cancellation lands — the await resumes normally and the increment
runs for a fetch the production hook will correctly discard. Add
`ct.ThrowIfCancellationRequested()` after the await so the fixture's
counter accurately reflects fetches that ran to completion versus
those that completed-then-got-discarded.

ThreadSafe_RenderCoalescing — split into honest + strict variants
──────────────────────────────────────────────────────────────────
The threshold "1000 setStates → fewer than 200 renders" was too
aggressive for the algorithm's actual semantics. Trace: the CAS
gate in RequestRender promises "at most one RenderLoop pending" —
not "many calls → ~1 render" — when the producer (Task.Run) runs
in parallel with an idle UI thread that drains RenderLoop between
each setState. Observed 436/1000 and 456/1000 = ~45% coalescing,
right in the alternation-dominant regime.

Two changes:

1) Existing background-thread fixture: relax threshold from
   `renders<200` to `renders<writes` (i.e., <1000). This proves
   *some* coalescing happened and catches a totally-broken-gate
   regression (which would give renders==writes), but does not
   over-claim a coalescing ratio the algorithm doesn't promise.
   Comment updated to reference the strict-coalescing sibling.

2) New ThreadSafe_RenderCoalescingDispatcherBatch fixture: fires
   1000 setStates from inside a single DispatcherQueue.TryEnqueue
   block on the UI thread. Because the UI thread is busy executing
   the loop, RenderLoop cannot drain between calls — every setState
   after the first finds the CAS gate held and is coalesced. This
   is the actual invariant the production gate is designed for, and
   should hold deterministically: renders<=5 (expected ~2).

Author: codemonkeychris

src/Reactor/Controls/Validation/Validators/BuiltInValidators.cs

@@ -157,11 +157,15 @@ public MatchValidator(string pattern, string message, string code = "MATCH")
         if (pattern is null) throw new ArgumentNullException(nameof(pattern));
         if (pattern.Length > MaxPatternLength)
             throw new ArgumentException($"Match pattern too long (>{MaxPatternLength} chars).", nameof(pattern));
-        // SECURITY (TASK-094): cap regex execution at 200ms so a pathological
-        // pattern can't tarpit the UI thread on every keystroke. 200ms matches
-        // the cap used elsewhere (DevtoolsPropertyTools, LogCaptureBuffer,
-        // WaitForPredicate) and tolerates cold-JIT under CI load.
-        _regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromMilliseconds(200));
+        // SECURITY (TASK-094): cap regex execution so a pathological pattern
+        // can't tarpit the UI thread on every keystroke. 1s rather than the
+        // 200ms used by diagnostic paths (DevtoolsPropertyTools, LogCaptureBuffer):
+        // RegexMatchTimeout is wall-clock, and under threadpool starvation a
+        // non-pathological match against a short input can blow past 200ms even
+        // though CPU time is microseconds. False-invalid validation on legitimate
+        // input is worse UX than slower tarpit detection on adversarial input,
+        // since the former affects every user on every CI-loaded environment.
+        _regex = new Regex(pattern, RegexOptions.Compiled, TimeSpan.FromSeconds(1));
         _message = message;
         _code = code;
     }

tests/Reactor.AppTests.Host/SelfTest/Fixtures/AsyncResourceFramerateFixtures.cs

@@ -72,6 +72,15 @@ public override async Task RunAsync()
                             {
                                 ct.Register(() => Interlocked.Increment(ref cancelled));
                                 await Task.Delay(200, ct);
+                                // Close the race where Task.Delay's 200ms timer
+                                // fires almost simultaneously with cancellation:
+                                // Task.Delay can complete normally (timer wins
+                                // the atomic result-set) even though Cancel()
+                                // was called, leaving the await to resume and
+                                // increment `completed` for a fetch the hook
+                                // will correctly discard. Re-checking the CT
+                                // after the await observes the cancellation.
+                                ct.ThrowIfCancellationRequested();
                                 Interlocked.Increment(ref completed);
                                 return $"dep={dep}";
                             }

tests/Reactor.AppTests.Host/SelfTest/Fixtures/ThreadSafeHookFixtures.cs

@@ -1,3 +1,4 @@
+using Microsoft.UI.Dispatching;
 using Microsoft.UI.Reactor;
 using Microsoft.UI.Reactor.Core;
 using Microsoft.UI.Reactor.AppTests.Host.SelfTest;
@@ -260,9 +261,14 @@ public override async Task RunAsync()
     // ════════════════════════════════════════════════════════════════════
 
     /// <summary>
-    /// Verifies that rapid setState calls coalesce into far fewer actual renders.
-    /// A component tracks its render count via UseRef. After 1000 rapid setState
-    /// calls, the render count should be much less than 1000.
+    /// Verifies that rapid background-thread setState calls coalesce into fewer
+    /// renders than calls. The CAS gate in RequestRender promises "at most one
+    /// RenderLoop pending at a time" — it does not promise N calls → ~1 render
+    /// when the producer runs in parallel with an idle UI thread, because the
+    /// UI thread can drain RenderLoop between each setState. Under that worst
+    /// case (multi-core CI runner, no real WinUI work to keep the UI thread
+    /// busy), coalescing ratio drops to ~50%. The strict-coalescing invariant
+    /// is tested by the sibling RenderCoalescingDispatcherBatch fixture.
     /// </summary>
     internal class RenderCoalescing(Harness h) : SelfTestFixtureBase(h)
     {
@@ -287,27 +293,89 @@ public override async Task RunAsync()
             H.Check("Coalesce_Initial", H.FindText("Value: 0") is not null);
 
             // Fire 1000 setState calls as fast as possible from one thread
+            const int writes = 1000;
             await Task.Run(() =>
             {
-                for (int i = 1; i <= 1000; i++)
+                for (int i = 1; i <= writes; i++)
                     setValue!(i);
             });
 
             await Harness.Render();
 
             H.Check("Coalesce_FinalValue", H.FindText("Value: 1000") is not null);
 
-            // Render count should be far less than 1000 due to coalescing.
-            // Threshold is loose (1/5 of writes) to tolerate scheduler interleaving
-            // on CI runners where the UI thread can sneak in renders between
-            // background-thread setState calls; full coalescing on a quiet machine
-            // produces ~2 renders.
+            // Honest threshold: renders < writes proves *some* coalescing happened
+            // (a totally broken gate would give renders == writes). The "strict"
+            // invariant — many calls collapse to ~1 render — only holds when the
+            // producer cannot be interleaved with RenderLoop, which is what the
+            // sibling RenderCoalescingDispatcherBatch fixture verifies.
             var renderText = H.FindControl<TextBlock>(tb =>
                 tb.Text?.StartsWith("Renders:") == true);
             if (renderText is not null)
             {
                 var renders = int.Parse(renderText.Text.Replace("Renders: ", ""));
-                H.Check($"Coalesce_FarFewerRenders (renders={renders})", renders < 200);
+                H.Check($"Coalesce_FewerRendersThanWrites (renders={renders}, writes={writes})", renders < writes);
+            }
+        }
+    }
+
+    // ════════════════════════════════════════════════════════════════════
+    //  Strict render coalescing: setStates inside one dispatcher block
+    // ════════════════════════════════════════════════════════════════════
+
+    /// <summary>
+    /// Strict-coalescing complement to RenderCoalescing. Fires 1000 setState
+    /// calls from inside a single DispatcherQueue.TryEnqueue block on the UI
+    /// thread. Because the UI thread is busy executing the loop, RenderLoop
+    /// cannot drain between calls — every setState after the first finds the
+    /// CAS gate held and is coalesced. Verifies the actual invariant the
+    /// production gate is designed for: a burst of setStates that arrive
+    /// faster than RenderLoop drains collapses to ~1 follow-up render.
+    /// </summary>
+    internal class RenderCoalescingDispatcherBatch(Harness h) : SelfTestFixtureBase(h)
+    {
+        public override async Task RunAsync()
+        {
+            Action<int>? setValue = null;
+
+            var host = H.CreateHost();
+            host.Mount(ctx =>
+            {
+                var (value, set) = ctx.UseState(0, threadSafe: true);
+                var renderCount = ctx.UseRef(0);
+                renderCount.Current++;
+                setValue = set;
+                return VStack(
+                    TextBlock($"Value: {value}"),
+                    TextBlock($"Renders: {renderCount.Current}")
+                );
+            });
+
+            await Harness.Render();
+            H.Check("CoalesceBatch_Initial", H.FindText("Value: 0") is not null);
+
+            const int writes = 1000;
+            var dq = DispatcherQueue.GetForCurrentThread();
+            var done = new TaskCompletionSource();
+            dq.TryEnqueue(() =>
+            {
+                for (int i = 1; i <= writes; i++) setValue!(i);
+                done.SetResult();
+            });
+            await done.Task;
+            await Harness.Render();
+
+            H.Check("CoalesceBatch_FinalValue", H.FindText("Value: 1000") is not null);
+
+            // Strict bound: 1000 writes inside one dispatcher block cannot
+            // schedule more than a handful of renders. Allow a small margin
+            // for any _needsRerender → re-enqueue paths after Render() drains.
+            var renderText = H.FindControl<TextBlock>(tb =>
+                tb.Text?.StartsWith("Renders:") == true);
+            if (renderText is not null)
+            {
+                var renders = int.Parse(renderText.Text.Replace("Renders: ", ""));
+                H.Check($"CoalesceBatch_StrictCoalescing (renders={renders}, writes={writes})", renders <= 5);
             }
         }
     }

tests/Reactor.AppTests.Host/SelfTest/SelfTestFixtureRegistry.cs

@@ -272,6 +272,7 @@ internal static class SelfTestFixtureRegistry
         "ThreadSafe_ReducerSerializationStress",
         "ThreadSafe_HighFrequencyLargeTree",
         "ThreadSafe_RenderCoalescing",
+        "ThreadSafe_RenderCoalescingDispatcherBatch",
         // Animation system — Curve & Easing
         "Curve_RecordEquality",
         "Curve_PresetValues",
@@ -1038,6 +1039,7 @@ internal static class SelfTestFixtureRegistry
         "ThreadSafe_ReducerSerializationStress" => new ThreadSafeHookFixtures.ReducerSerializationStress(harness),
         "ThreadSafe_HighFrequencyLargeTree" => new ThreadSafeHookFixtures.HighFrequencyLargeTree(harness),
         "ThreadSafe_RenderCoalescing" => new ThreadSafeHookFixtures.RenderCoalescing(harness),
+        "ThreadSafe_RenderCoalescingDispatcherBatch" => new ThreadSafeHookFixtures.RenderCoalescingDispatcherBatch(harness),
         // Animation system — Curve & Easing
         "Curve_RecordEquality" => new CurveTests.RecordEquality(harness),
         "Curve_PresetValues" => new CurveTests.PresetValues(harness),