FakeHttpMessageHandler test double isn't thread-safe

[spbsoluble]

Deferred from #6 (review-findings-of-review-findings pass), flagged for triage before GA. Test-only, not a production issue - latent CI flakiness risk.

Where

markmonitor-caplugin.Tests/TestHelpers/FakeHttpMessageHandler.cs:

public sealed class FakeHttpMessageHandler : HttpMessageHandler
{
    private sealed class Route
    {
        public required Func<HttpRequestMessage, bool> Matches;
        public required Queue<Func<HttpRequestMessage, Task<HttpResponseMessage>>> Responses;
    }

    private readonly List<Route> _routes = new();
    public List<HttpRequestMessage> Requests { get; } = new();

Problem

_routes, Requests, and each Route.Responses are plain, unsynchronized collections. Tests that
exercise genuine concurrency (the dedup-cache race tests and the auth double-checked-locking tests
added/touched in #6) send concurrent requests through a single shared handler instance, which reads
Requests.Add(...) and dequeues from Route.Responses without any locking. This works today (the
races these tests are asserting on are in the client's own locking, not the fake handler's plumbing),
but a future concurrent test that increases contention could hit a Queue<T>/List<T> corruption or
a missed/duplicated request record - flaky in a way that's hard to distinguish from a genuine
product-code race being tested for.

Suggested fix

Make _routes/Requests thread-safe (e.g. ConcurrentQueue/lock around mutation and enumeration),
or document that concurrent tests must not rely on Requests ordering/count being exact under
contention.