fix(cli): complete SDK invocation isolation

[betegon]

Logging in through one SDK call could break a pending request from another call, even when they used separate config directories and separate stored logins.

For example, a request starts with login A's credentials, then A refreshes its token. Auth records that the old and new credentials belong to the same login, so the pending request can continue. But logging in through a separate config directory B cleared that record globally. A's request could then fail with Active credentials changed, even though A's login was still valid.

The basic sequential token-switching bug reported in #1391 is already fixed on main. This PR addresses the remaining shared-state and cleanup problems.

Fix

Give each kind of state the lifetime it needs:

• Invocation — one SDK call: capture its environment and headers, and keep temporary auth, routing, and cache flags with that call. Any unfinished async work retains the same context.
• Request — one HTTP operation: reuse the existing credential snapshot and require its identity explicitly for cache reads and writes. A late response is still associated with the identity selected for that request.
• Session — a stored login reused across calls: keep refresh coordination and the record of old-to-new credentials scoped to its config database. Logging in through B cannot erase A's refresh history. Calls using the same database still share the same session.

flowchart TB
    subgraph invocation["Invocation: one SDK call and its async work"]
        context["Captured environment and headers<br/>Temporary routing and cache flags"]
        request["Request: one HTTP operation<br/>Selected credential snapshot"]
        context --> request
    end

    subgraph session["Session: shared by calls using the same config database"]
        credentials["Stored login"]
        refresh["In-memory refresh coordination<br/>and old-to-new credential history"]
    end

    credentials -->|Credential snapshot| request
    request -->|Refresh when needed| refresh
    refresh -->|Updated token for the same session| request
    request -->|Explicit request identity and headers| cache["Response cache<br/>Entries scoped by identity"]

Loading

The session and response cache can outlive a single SDK call. Temporary invocation state stays attached to the call that created it; refresh history is shared only within its credential store.

For streams, cancellation also has to respect that lifetime: a dashboard cancelled during its initial fetch must finish without yielding the fetched value or starting its refresh loop. Iterator return now waits for producer cleanup. The SDK enforces its documented sequential-call contract by rejecting another call until the active invocation finishes cleanup.

Before / after

Scenario	Before	After
A refreshes its credentials, then a login occurs in separate config directory B while A's request is pending.	B clears A's refresh history; A can fail with Active credentials changed.	B only clears its own history; A's request can continue using its refreshed credentials.
A dashboard is cancelled during its initial fetch.	The iterator still yields a dashboard when the fetch finishes.	The iterator finishes without yielding that dashboard or starting the refresh loop.
Another SDK call starts while a call or stream is active.	Calls can overlap despite the documented sequential-only contract.	The second call rejects with SentryError; it can run after the first finishes cleanup.

Fixes #1391.

Validation

• pnpm run tsc, root pnpm run lint, and CLI pnpm run lint: pass.
• TZ=UTC pnpm run test: shared Toolkit helpers, CLI docs, MCP core, MCP server, MCP Cloudflare, and MCP test-client suites pass. CLI: 10,584 passed, 14 skipped, 1 failed.
• The remaining failure is the musl installer fixture previously reproduced on clean main on macOS. Installer files are unchanged from the PR base. The full root test command therefore remains non-green.
• SDK invocation isolation, request/cache ownership, credential-store refresh history, and stream cleanup regressions pass. Restoring global refresh-history clearing or removing the producer-cleanup wait was also verified to break the corresponding tests.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit c376649. Configure here.}