fix(supply-chain): tell Dependabot why mcp is held below 2 — it proposed lifting it twice (INV-SUPPLY-2)

[neosun100]

The gap

mcp>=1.0,<2 was stated in three places Dependabot cannot read — a long pyproject.toml comment, INV-MCP-5 in docs/INVARIANTS.md, and tests/test_mcp_version_bound.py. So it proposed lifting the bound twice in one week:

PR	change	effect
#59	pyproject.toml: mcp>=1.0,<2 → mcp>=1.0,<3	widens the range
#60	specialists/*: mcp==1.28.1 → mcp==2.0.0	pins the deployed containers to it

PR #60 came from the container coverage added last round (INV-SUPPLY-1) — the very first PR that entry produced would have shipped a breaking version into the Runtime images.

Re-verified, not trusted from the record

A bound whose evidence has expired is worse than no bound, so both were measured against the real 2.0.0 release:

from mcp.server import Server                                 -> OK      <-- proves nothing
Server("probe").list_tools / .call_tool                       -> GONE
create_server()  -> AttributeError: 'Server' object has no attribute 'list_tools'

from mcp import ClientSession                                 -> OK
from mcp.client.streamable_http import streamablehttp_client   -> ImportError

The first block confirms INV-MCP-5's own recorded lesson: an import check is not a compatibility check.

The second block is what could have been missed. The root bound is about the server surface, which the specialists never touch — they use the client surface, so "the same bound applies" was an assumption that needed its own measurement. It held, for an independent reason: all four specialists/*/agent_a2a.py import streamablehttp_client, which 2.0 also removed. Two separate breakages behind one version number.

Fix

Declare the bound in .github/dependabot.yml — the one file Dependabot reads — with its evidence and its lift procedure. This generalises what iac-cdk's TypeScript bound already did right (INV-IAC): "a fix applied to one call site is not an invariant", applied to a supply-chain declaration.

The non-obvious detail the guard encodes

ignore is per-update-block, not global. The root pip entry's ignore does not cover the container pip entry — which is exactly why PR #60 existed — so a guard checking merely "mcp is ignored somewhere" would have passed while the dangerous PR was open. Every block of the relevant ecosystem is checked.

Also asserted:

• Each ignore carries a version range. A bare ignore: mcp silently blocks 1.x security patches too, turning a compatibility bound into an unmaintained dependency.
• The pyproject bound and the ignore describe the same boundary. Widening to <3 while the ignore stays at >=2.0.0 is the worst combination: the repo permits a version Dependabot has stopped warning about — the guard that would complain is the one now disabled.
• The file records how to re-verify, so the bound gets lifted deliberately rather than becoming permanent by default.

Verification

• New guard: 7 passed. Mutation-tested 7/7, including the exact PR chore(deps): update mcp requirement from <2,>=1.0 to >=1.0,<3 in the python-dev group #59 and PR chore(deps): bump the container-runtime group across 5 directories with 5 updates #60 conditions (remove the root ignore; remove the container ignore), plus: ignore with no version range, stripped evidence, removed re-verify command, removed TypeScript precedent, and widening pyproject to <3 while the ignore stays.
• Config re-validated against the official dependabot-2.0 JSON schema.
• Counts synced repo-wide (4039→4073 tests, 171→175 files, +6→+8 skipped) — the file count had drifted 4 past test_docs_drift's ±3 tolerance, which is that guard doing its job.
• Full suite: 4074 passed / 8 skipped. ruff clean.

PRs #59 and #60 should be closed once this merges; the ignore entries stop them recurring.