FetchOrderAsync sets the shared HttpClient's Authorization header outside _authLock

[spbsoluble]

Deferred from #6 (review-findings-of-review-findings pass), flagged for triage before GA.

Where

MarkMonitorClient.FetchOrderAsync (markmonitor-caplugin/Client/MarkMonitorClient.cs:483):

private async Task<OrderContent> FetchOrderAsync(string orderId)
{
    ...
    _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", _bearerToken);

Problem

This assigns the shared HttpClient's Authorization header directly, outside _authLock. It's a
narrower race than the one EnsureAuthenticatedAsync's double-checked locking (see
markmonitor-caplugin/Client/MarkMonitorClient.cs:1130) was built to close: two concurrent
FetchOrderAsync calls (or one racing a concurrent re-authentication) can interleave writes to the
same header, so a request can go out under the wrong caller's token, or under a token that's
mid-write.

Suggested fix

Route this assignment through the same lock discipline as EnsureAuthenticatedAsync/
AuthenticateAsync, or read _bearerToken under the lock and pass it explicitly rather than
mutating the shared client's default header from an unguarded call site.