REV-2277: Attach active team UID header at the GraphQL v2 chokepoint

[warp-agent-staging]

Description

Adds the single chokepoint the client half of REV-2206 asked for: a place to attach the X-Warp-Active-Team-UID header to outbound GraphQL v2 requests so all GraphQL endpoints get the active team by default.

This PR is stacked on #15305 ("Send the active window's team UID on agent-mode requests") and branches off factory/rev-2206-team-uid-header, reusing http_client::headers::WARP_ACTIVE_TEAM_UID from that PR. The server counterpart is warp-server#15616 (REV-2274).

Chokepoint: BaseClient::graphql_request_options in crates/warp_server_client/src/base_client.rs — the same function every GraphQL v2 call already funnels through via send_graphql_request/RequestOptions.headers, attached the same way as the existing ambient headers.

Team source seam (provisional, awaiting requester confirmation): warp_server_client::base_client::ActiveTeamUid is a small Arc<RwLock<Option<String>>> handle. graphql_request_options only reads it (None omits the header entirely — a strict no-op against today's server). UserWorkspaces (app/src/workspaces/user_workspaces.rs) is the one place that writes to it, keeping it synced to the focused window's current team via the existing team_for_window (which resolves to None for a window with no assignment or a stale assignment reconcile_window_team_assignments hasn't yet corrected — no invented fallback). It resyncs whenever the focused window changes (subscribing to WindowManager's tracked state) and whenever a window's team assignment or the workspace list changes.

Account boundaries: AuthManager clears the seam directly (via ServerApiProvider::active_team_uid_handle) at every auth-session teardown (log_out) and at every fresh login/account switch (on_user_fetched when !from_refresh), before any of that session's own GraphQL work starts. This prevents a stale team UID from a previous session/account from leaking onto a new one before UserWorkspaces has a chance to resync.

Open question: the requester (Tyler Lam) hasn't confirmed whether "active team" for windowless GraphQL calls should be the focused window's team (what this PR implements), a separately persisted active team, or omitted entirely. This PR is built so that answer only requires changing what calls ActiveTeamUid::set — the header plumbing in BaseClient doesn't change either way.

Linked Issue

• Linear: REV-2277 (client half of parent tracking issue REV-2206)
• Not tracked by a GitHub issue, so the ready-to-spec/ready-to-implement checklist doesn't apply here.

Testing

• Added/extended unit tests in crates/warp_server_client/src/base_client_tests.rs: the header is omitted by default, attached once ActiveTeamUid::set is called, cleared when set back to None, and cannot be overridden via AuthenticatedGraphqlConfig's static header configuration.
• Added tests in app/src/workspaces/user_workspaces_tests.rs exercising the UserWorkspaces → ActiveTeamUid wiring: the active team follows the focused window's assignment (and only the focused window's), an unmapped or never-valid focused window omits the header rather than falling back, and switching the current workspace resyncs to the reconciled team.
• Added a regression test in app/src/auth/auth_manager_tests.rs pinning that log_out clears the active-team seam. Note: I did not add an end-to-end test through AuthManager::on_user_fetched's success path (the fresh-login/account-switch clearing) — that path touches roughly 10 additional singletons (SettingsInitializer, UpdateManager, TeamTesterStatus, CloudPreferencesSyncer, LLMPreferences, PersistedWorkspace, GeneralSettings, SharedSessionManager, GlobalResourceHandlesProvider, PrivacySettings) that no existing test of this function currently registers, so it isn't cheap. The clearing reuses the exact from_refresh signal that adjacent, already-relied-upon code in the same function uses for identical identity-vs-refresh semantics.
• Ran cargo test -p warp_server_client --lib (50/50 passed), cargo test -p warp --lib workspaces::user_workspaces (56/56 passed), and cargo test -p warp --lib auth::auth_manager (10/10 passed).
• Ran cargo clippy -p warp_server_client --all-targets --all-features -- -D warnings and cargo clippy -p warp --lib --tests -- -D warnings; both clean. Ran ./script/format; no changes.
• I have manually tested my changes locally with ./script/run

Not verified: I could not manually run the full desktop app in this sandbox (no display, and this repo's heavier cargo invocations have been OOM-killed in small environments before — a single cargo check -p warp --lib invocation takes ~2 minutes and is close to what this environment can comfortably handle). I also could not run some warp_server_client tests under their default configuration: this sandbox's isolation-platform detection finds NSC_TOKEN_FILE set (it runs on Namespace infrastructure) but lacks the nsc binary, so ambient_headers() fails before the code under test runs. I confirmed via git stash that this reproduces identically on the unmodified base branch, so it's a pre-existing sandbox limitation, not a regression; all tests pass with WARP_ISOLATION_PLATFORM=docker set to work around it locally.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-factory on this PR to send it follow-up work.