fix(deps): drop fastmcp for the official mcp SDK; pin urllib3 for CVE fixes

[pjdoland]

Summary

Two related fixes:

1. NBI's pyproject.toml on main is currently un-installable on a fresh Python 3.14 environment. litellm>=1.83.7 (the floor that picks up CVE-2026-42203 / CVE-2026-42208 / CVE-2026-42271 fixes) hard-pins python-dotenv==1.0.1, and every fastmcp>=2.11.2 release requires python-dotenv>=1.1.0. The constraints are mutually unsatisfiable; pip install -e . reports ResolutionImpossible. Verified in a clean venv.

   This PR drops the fastmcp dep entirely and routes mcp_manager.py through a thin local shim implemented against the official mcp Python SDK, which lists python-dotenv only as an optional cli extra and is already in NBI's dep tree via claude-agent-sdk. Fresh installs succeed.

2. urllib3 2.6.3 has two open CVEs. Pinned urllib3>=2.7.0 to pick up CVE-2026-44431 (cross-origin redirect handling) and CVE-2026-44432 (streaming API). Reaches NBI via requests, which doesn't cap the upper bound, so a single lower bound in NBI's pyproject is enough.

Solution

fastmcp → mcp swap (notebook_intelligence/mcp_client.py, new file):

• Thin shim exposing the subset of fastmcp's surface NBI used (Client, StdioTransport, StreamableHttpTransport) implemented on top of the official mcp SDK. Constructor signatures and method shapes match fastmcp's so the call sites in mcp_manager.py change in two lines (the two imports).
• Return values are unchanged: the underlying Pydantic models are the same in both libraries, since fastmcp itself is a thin layer over mcp.
• pyproject.toml: fastmcp>=2.11.2 → mcp>=1.27.0. The python-dotenv resolution now lands on 1.0.1 (forced by litellm; CVE-2026-28684 affects only set_key / unset_key write paths which neither NBI nor any other dep exercises).

urllib3 pin (pyproject.toml):

• One added line: "urllib3>=2.7.0". Comment explains the transitive path through requests and which CVEs the bump addresses.

Testing

• tests/test_mcp_client_shim.py (5 new cases): constructor parity, programmer-error guards (methods-before-context, unsupported transport), and an end-to-end smoke test against a real stdio MCP server (spawns a subprocess, drives ping / list_tools / call_tool / list_prompts / get_prompt, asserts the exact attribute paths mcp_manager.py reads off the responses). Plus a cleanup-on-failure case that pins the stdio subprocess unwinds cleanly when initialization fails.
• Full pytest suite: 1012 passed. TS gates clean. End-to-end stdio test runs in under a second.
• Fresh-venv install verification: python -m venv /tmp/fresh && /tmp/fresh/bin/pip install -e . on Python 3.14 now succeeds. Previously: ResolutionImpossible.

Why this is the right temporary fix

The principled fix lives upstream in BerriAI/litellm#25231 (relax the python-dotenv pin from ==1.0.1 to >=1.0.1). That PR has been open since 2026-04-06 with no maintainer engagement, and a parallel CVE-fix bump (#26435) was closed without merge. NBI can't ship a working install while waiting on upstream.

The shim is small (~120 lines), tested end-to-end, and the docstring + pyproject comment both point at the upstream PR to revert to once it lands. The official mcp SDK is a stable Anthropic-maintained library, not a vendored fork — there's no maintenance burden beyond keeping the shim's method signatures aligned with mcp's public API.

Tracked upstream:

• fix: relax python-dotenv pin from ==1.0.1 to >=1.0.1 BerriAI/litellm#25231 — relax python-dotenv pin (open, 7 weeks no movement)
• fix: bump python-dotenv to 1.2.2 to fix CVE-2026-28684 BerriAI/litellm#26435 — bump python-dotenv to 1.2.2 for CVE-2026-28684 (closed without merge)

Risks

• None practically expected. The full pytest suite stays green. The end-to-end shim test exercises every method mcp_manager.py calls. JupyterLab's MCP integration paths haven't been touched.
• The shim is a new module to learn; the docstring lays out exactly why it exists and how to revert. Two imports in mcp_manager.py change shape; the consumer behavior is byte-for-byte identical.