fix(ci): cap mcp below 2.0 — the backend suite has not run since 2026-07-29

mcp 2.0.0 shipped on 2026-07-28 and deleted mcp.server.fastmcp, the module
app/mcp/server.py imports. requirements.txt asked for `mcp>=1.0.0` with no
ceiling, so the very next CI run resolved the new major and died importing
test_mcp_tools.py.

That failure is a COLLECTION error, not a test failure: pytest aborts with
exit 2 before running anything, so all 295 unit tests have been silently
unrun on every push since. The workflow was red, but red for a reason
nobody's code caused.

The deploy venv escaped only by accident — it was built while 1.x was still
current, and deploy.sh rebuilds it when requirements.txt changes, so the
next rebuild would have walked into the same wall and taken the deploy gate
down with it.

Verified in a clean venv built from this file: resolves to mcp 1.29.0,
322 passed / 18 skipped, test_mcp_tools.py's 35 tests among them.

Raising the cap means porting to the 2.x server API (mcp.server.mcpserver).

backend/requirements.txt

@@ -9,7 +9,14 @@ pydantic>=2.11.0
 pydantic-settings>=2.6.0
 # httpx — iot_gateway proxy + MCP
 httpx>=0.27.1
-mcp>=1.0.0
+# Capped below 2.0: mcp 2.0.0 (2026-07-28) deleted mcp.server.fastmcp, which
+# app/mcp/server.py imports. The unbounded `>=1.0.0` meant CI resolved the new
+# major the next day and every Backend Unit Tests run since 2026-07-29 died at
+# COLLECTION — pytest exit 2, all 295 unit tests silently unrun. The deploy
+# venv only escaped because it was built before 2.0.0 shipped; its next
+# requirements-triggered rebuild would have hit the same wall.
+# Lifting the cap means porting to the 2.x server API (mcp.server.mcpserver).
+mcp>=1.0.0,<2
 esptool>=4.7.0
 # WASM runtime for Custom Chips on ESP32 (chip's WASM runs in the QEMU worker
 # subprocess so I2C events get a synchronous response — see