fix(mcp): unblock nightly with issuer-safe SDK upgrade

[ARE404]

Summary

The npm nightly publication fails its shipped-dependency audit on GHSA-6qxp-vccf-f47h, preventing the downstream Desktop Nightly from running. Upgrade @modelcontextprotocol/client and its core dependency to 2.2.0 and rebase the existing request-observer lifetime patch without changing its behavior. Refresh CLI and Desktop third-party notices.

Follow the advisory's migration guidance by revoking persisted OAuth credentials that have no issuer binding, requiring a fresh sign-in. Keep existing OAuth fixtures issuer-bound so refresh, logout-race, and endpoint-binding tests continue to exercise their intended paths.

Refs: https://github.com/apache/maka/actions/runs/37753749720

Verification

• Reproduced the original shipped audit failure on main; the same audit reports 0 moderate-or-higher shipped advisories after the upgrade (342 packages).
• Added the legacy-credential regression and observed it fail before the provider fix; all 262 MCP tests pass after rebuilding.
• Clean install with the pinned npm 11.19.0 and dependency patch application pass.
• Full build, typecheck, lint, format checks, and knip for Desktop/UI pass.
• Shipped-audit, dependency-closure, and notice tests pass; both generated notice checks pass.
• The official nightly publication has not been rerun with this branch; it requires the change on main.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: OpenAI Codex implemented and locally validated this change.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

Reviewed the 2.1.0 → 2.2.0 upgrade for GHSA-6qxp-vccf-f47h.

• Patch port is correct. The hunk bodies are byte-identical; only the chunk filenames and line offsets changed. git apply --check passes against the npm 2.2.0 tarball, and Protocol exists only in the two patched chunks.
• Housekeeping is complete. patches/README.md, LICENSE, and the CLI and Desktop notices are updated. Lockfile integrities match the registry, and client 2.2.0's dependency set only changes core.
• The OAuth change is sound.
  • SDK auth() stamps issuer on every save in both 2.1.0 and 2.2.0.
  • Our storage backends round-trip JSON, so the stamp persists.
  • Pre-registered clients return issuer from config.
  • Discovery, AS-change and iss validation paths are unchanged.
  • Revoking unstamped legacy records matches the advisory's required app-side step, and background connects fall back to needs-auth rather than looping.
• Build immutable tarball and audit now pass.

P3 (merge coordination; lead ruling: not a defect in this PR)

• CI test is red on one Desktop E2E case (e2e/workhub-layout.spec.ts:156, "session closed"). It is unrelated to this diff and main is green. Please re-run before merge.
• #5969 contains byte-identical copies of this SDK bump (LICENSE, patch rename, packages/mcp/package.json, lockfile, notices) but not the oauth.ts revocation. Suggest landing this PR first and having #5969 drop its duplicate hunks on rebase. #5969 is currently conflicting anyway.

P3

• oauth.ts:409: revocation is silent. A diagnostic log carrying only the server id would help distinguish "legacy credential revoked by upgrade" from an ordinary expiry.
• Optional: add an E2E test through McpClientManager for the legacy-record → needs-auth path.
• FYI: dev-only @modelcontextprotocol/sdk@1.30.1 is still in the advisory range. It is not shipped, but is worth a follow-up bump.

Mergeable; awaiting review. No runtime-host protocol changes, so no epoch impact.

[Astro-Han]

P3: This is the right call per the advisory ("clear them so users sign in again"). Since read() deletes the record silently, consider emitting a one-time diagnostic line (server id only, no secrets) when missingIssuer triggers. That way support can tell an upgrade-driven revocation apart from an ordinary expired token when a user lands on needs-auth after updating.

[Astro-Han]

P3 (merge coordination): #5969 carries an identical bump of this dependency, plus the same LICENSE, patch-rename, lockfile and notice hunks, but not the oauth.ts legacy-credential revocation. If #5969 lands first, the audit goes green without the advisory's required app-side step. Suggest merging this PR first and asking #5969 to drop its duplicate SDK hunks on rebase.