test(concurrency): clear the seven InspectCode alerts in ConcurrencyStressTests

[Chris-Wolfgang]

Summary

All 7 open code-scanning alerts are InspectCode warnings in the ConcurrencyStressTests.cs added by #376. Each is a real finding, fixed rather than suppressed:

Rule	Lines	Fix
AccessToModifiedClosure	136, 172	The counters are StrongBox<int>, so each lambda captures a reference that never changes. The count is only touched through Interlocked.Increment(ref box.Value) / Volatile.Read(ref box.Value).
AsyncFixer06	137, 177	Record.ExceptionAsync(async () => await call) replaces the implicit Task<Result> → Task lambda conversion.
xUnit1031	147, 187 (×2)	No blocking call.Result. When the call didn't throw it is awaited once (thrown is null ? await call : null), and the assertion pattern-matches that value (result is { Succeeded: true, Value: 42 }).

The test invariants are unchanged.

Verification

• Local InspectCode, run the same way as CI (jb inspectcode TryPattern.sln --severity=WARNING --no-build after a solution build):
  • control on origin/main's file: exactly the 7 CI findings (same rules, same lines);
  • this branch: 0 results for the whole solution.
• dotnet build -c Release -p:TreatWarningsAsErrors=true: 0 errors.
• Tests: 5/5 at the default 100 rounds and 5/5 at STRESS_ITERATIONS=20000. Both race outcomes still occur: the cancel won 36/100 and 2/100 rounds.
• Coverage: Wolfgang.TryPattern.Tests.Concurrency still at 100%, so it passes the new test-assembly gate.

Also: the macOS coverage flake (second commit)

The first CI run failed only Stage 3 (macOS ARM64): Tests.Unit at 99%, with RunAsyncActionTests at 98.9% and line 256, the while (true) loop-back, uncovered in both macOS reports. #383's reorder only narrowed the race: the cancel could still land between TrySetResult and ThrowIfCancellationRequested(), so the loop never went round a second time.

The action in RunAsync_Action_CancellationToken_when_cancellation_is_requested_after_action_started_the_action_is_cancelled is now straight-line:

• it signals started;
• it blocks on the token's WaitHandle (10 s timeout, so a missing cancel fails instead of hanging);
• it records whether the cancellation was seen;
• it ends with an unconditional throw new OperationCanceledException(token).

With no loop and no reachable normal exit, the compiler emits no closing-brace sequence point. A trailing ThrowIfCancellationRequested() had left those braces uncovered on every run. The test still asserts that RunAsync propagates the OperationCanceledException, and now also asserts that the action observed the cancellation.

Verified: 200/200 repeated runs on net10.0. RunAsyncActionTests has no uncovered lines in any single-framework report (net48, net6.0–net10.0), so coverage no longer depends on timing. On the macOS framework set, Tests.Unit is at 100%.

Closes #384
Closes #385
Closes #386
Closes #387
Closes #388
Closes #389
Closes #390

🤖 Generated with Claude Code