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 and root pnpm run lint: pass.
• CLI pnpm run lint and normal pre-commit hooks: pass.
• CJS and ESM bundles build; both pass the public SDK smoke test: A → B → malformed token → cached A, with two mocked HTTP requests and unchanged process.env.
• Final full CLI suite: 10,536 passed, 14 skipped, 1 failed. The musl installer fixture also fails on clean main on macOS. The root test command stops at this CLI failure, so subsequent workspace suites were not validated.
• An issue-unlink assertion failed in an earlier run and reproduced on clean main; it passed in the final suite. Neither baseline failure is changed here.