[medium] interactiveOAuthMu.Lock() is not context-aware: a cancelled toolset blocks indefinitely waiting behind an active OAuth flow

Trigger: This PR introduces concurrent toolset startup. If toolset A is in an interactive OAuth flow (waiting for user browser interaction, which can take minutes), toolset B — started concurrently — can also reach startInteractiveFlowLocked and block at interactiveOAuthMu.Lock() on line 492. If toolset B's ctx is cancelled before it acquires the mutex (e.g. the agent session is torn down, a startup timeout fires, or the user cancels), sync.Mutex.Lock() is not context-aware and cannot be interrupted. Toolset B's goroutine is stuck behind the user interaction for toolset A.

Impact: While blocked at interactiveOAuthMu.Lock(), toolset B's goroutine still holds oauthFlowMu (acquired by the caller authorizeOnce). Every concurrent RPC to toolset B's transport that also needs oauthFlowMu is therefore also stalled — potentially for minutes — even though toolset B's context is already cancelled. Once toolset B finally acquires interactiveOAuthMu, it calls handleOAuthFlow(ctx, ...) and returns immediately (cancelled context), but the delay was already paid. Before this PR sequential startup meant only one toolset could be doing OAuth at a time, so this scenario could not arise.

Suggested fix: Replace the bare sync.Mutex with a context-aware acquire that selects on ctx.Done():

acquired := make(chan struct{}, 1)
go func() { interactiveOAuthMu.Lock(); acquired <- struct{}{} }()
select {
case <-acquired:
    defer interactiveOAuthMu.Unlock()
case <-ctx.Done():
    return ctx.Err()
}

Or use a sync.Cond-based approach, or a channel-based semaphore, to allow waiting goroutines to be preempted on context cancellation.

[medium] Holding per-transport oauthFlowMu while blocking on global interactiveOAuthMu can stall concurrent RPC calls for the duration of another transport's interactive OAuth flow

authorizeOnce acquires t.oauthFlowMu, then calls startInteractiveFlowLocked, which blocks on the process-wide interactiveOAuthMu. Before this PR, toolsets started sequentially, so Transport A's OAuth would never begin while Transport B's user-facing flow was in progress. Now that toolsets start concurrently, Transport A can be holding its own per-transport t.oauthFlowMu while waiting for Transport B's user to click "Authorize" in the browser — a wait measured in minutes.

During that entire window, any concurrent RoundTrip call for Transport A that encounters a 401 and calls authorizeOnce will block on t.oauthFlowMu with its request context ticking down, potentially timing out. The comment in the code acknowledges this lock ordering but does not address the extended hold duration introduced by concurrency.

A low-risk mitigation: acquire interactiveOAuthMu before t.oauthFlowMu (i.e. restructure authorizeOnce to try the cheap token-check first without holding oauthFlowMu, and only take t.oauthFlowMu for the minimal critical section). Alternatively, document that callers must use a context with a timeout long enough to survive a full interactive flow.

[low] Prefetch winning the sync.Once race with a transient error permanently prevents catalog loading for this process lifetime

Prefetch fires go func() { _, _ = loader.load(ctx) }() in the background. Inside load, sync.Once memoizes the first result — including errors — so a transient failure during the prefetch window permanently caches the error; no subsequent ServerSpec call can retry.

Before this PR, Prefetch did not exist, so the once.Do was triggered only by a real ServerSpec call (at which point the caller could propagate the error and the user could retry by restarting). Now the once.Do fires at load time, in the background, when the caller has no visibility.

fetchAndCache does have a disk-cache fallback, so a pure network blip is unlikely to produce an error (it would return the cached catalog instead). The residual scenario is: no network AND no on-disk cache (cold start on first run with no connectivity). In that case, the process must be restarted to retry, whereas before this PR the first real call would fail immediately and the user could react.

Consider returning the error through a channel or logging it at WARN level so the failure is visible, and/or not entering once.Do from the background goroutine (only trigger the fetch eagerly without committing the error result — keep once.Do solely on the real call path).