fix(copaw): pin mcp below 2.0.0 in copaw-worker

[LUOSENGWA]

What

Adds one constraint to copaw-worker dependencies (copaw/pyproject.toml):

"mcp>=1.13,<2.0.0",

Why

• The MCP Python SDK renamed its client entrypoint in 2.0.0 (2026-07-27):
  mcp.client.streamable_http.streamablehttp_client → streamable_http_client (breaking rename;
  verified against the published mcp-2.1.1 wheel source).
• copaw 1.0.2 (PyPI) still imports the legacy name unconditionally at worker startup
  (app MCP client module, line 9: from mcp.client.streamable_http import streamablehttp_client).
• The copaw-worker dependency chain declares mcp without an upper cap:
  copaw-worker 1.0.3 → copaw 1.0.2 → agentscope 1.0.18 → mcp>=1.13.
• Since mcp 2.1.1 was published (2026-08-25), any fresh image build resolves mcp 2.1.1,
  so every CoPaw worker container crashes at startup:
  ImportError: cannot import name 'streamablehttp_client' from 'mcp.client.streamable_http'
  (container exits 1 within ~4s).

Evidence (CI, 2026-09-01)

• copaw-worker build log:
  Collecting mcp>=1.13 (from agentscope==1.0.18->copaw==1.0.2->copaw-worker==1.0.3)
  → Downloading mcp-2.1.1-py3-none-any.whl.
• Every SHARD_C shard (openclaw/copaw/qwenpaw manager × copaw/hermes/qwenpaw worker) fails the
  copaw→qwenpaw migration test: Unable to create CoPaw runtime state + 3 cascading assertions
  (state not persisted / not active / incomplete); the copaw/copaw shard additionally loses the
  team lifecycle tests (workers run the default copaw runtime → crash loop).
• Reproduced locally with the same resolver: pip install --dry-run copaw==1.0.2
  → mcp-2.1.1; with the added cap → mcp-1.29.1.
• Control group (unaffected): the qwenpaw worker image pins mcp<2.0.0 via
  agentscope 2.0.4.post1 (resolves 1.29.1); manager-qwenpaw uses the same chain;
  openclaw/hermes workers do not import the legacy name.

Fix

A single dependency line. pip intersects it with agentscope's mcp>=1.13, so resolution
returns 1.29.1 (the last 1.x line — the version CI has been green on). The constraint is in
copaw-worker itself, so it covers both venvs of the copaw-worker image (standard = copaw
from PyPI, lite = GitHub fork).

No code changes; no behavior change for correctly-running workers.

Test plan

• CI build-images (copaw-worker) resolves mcp 1.29.1.
• SHARD_C copaw→qwenpaw migration tests and copaw-runtime team tests go green again.
• Re-runs of PRs whose only red job is SHARD_C should pass once this lands.

---

改了什么

copaw-worker 依赖（copaw/pyproject.toml）加一行上限：

"mcp>=1.13,<2.0.0",

为什么

• MCP Python SDK 在 2.0.0（2026-07-27）把客户端入口改名（breaking）：
  mcp.client.streamable_http.streamablehttp_client → streamable_http_client
  （已对照发布的 mcp-2.1.1 wheel 源码验证）。
• copaw 1.0.2（PyPI）启动时仍无条件 import 旧名（应用 MCP 客户端模块第 9 行）。
• copaw-worker 依赖链对 mcp 没有上限：
  copaw-worker 1.0.3 → copaw 1.0.2 → agentscope 1.0.18 → mcp>=1.13。
• mcp 2.1.1（2026-08-25 发布）之后，任何新构建都解析到 2.1.1，
  导致所有 CoPaw worker 容器启动即崩：
  ImportError: cannot import name 'streamablehttp_client' from 'mcp.client.streamable_http'
  （容器 ~4 秒内 exit 1）。

证据（CI，2026-09-01）

• copaw-worker 构建日志：Collecting mcp>=1.13 (from agentscope==1.0.18->copaw==1.0.2->copaw-worker==1.0.3)
  → Downloading mcp-2.1.1-py3-none-any.whl。
• 全部 4 个 SHARD_C shard（openclaw/copaw/qwenpaw × copaw/hermes/qwenpaw）的
  copaw→qwenpaw 迁移测试失败（Unable to create CoPaw runtime state + 3 条级联断言）；
  copaw/copaw shard 另挂团队生命周期测试（worker 默认 copaw runtime → 崩溃重启循环）。
• 本地用同一 resolver 复现：无上限 → mcp-2.1.1；加上限 → mcp-1.29.1。
• 对照组（不受影响）：qwenpaw worker 经 agentscope 2.0.4.post1 pin mcp<2.0.0
  （解析 1.29.1）；manager-qwenpaw 同链；openclaw/hermes worker 不 import 旧名。

修复方式

一行依赖约束。pip 与 agentscope 的 mcp>=1.13 求交集 → 解析回 1.29.1
（1.x 末版，CI 一直绿的版本）。约束放在 copaw-worker 自身，
因此同时覆盖镜像的两个 venv（standard = PyPI copaw，lite = GitHub fork）。

无代码改动；对正常运行的 worker 无行为变化。

验证

• CI build-images (copaw-worker) 解析出 mcp 1.29.1。
• SHARD_C 迁移测试与 copaw-runtime 团队测试恢复绿。
• 本 PR 合并后，仅 SHARD_C 红的在飞 PR 重跑即可转绿。

[shiyiyue1102]

LGTM. This isolates the CoPaw/MCP compatibility hotfix into a focused dependency PR. The copaw-worker build confirms that both installation paths end with mcp 1.29.1, and all affected integration shards are green again.

After this merges, #1208–#1212 should be rebased to drop their duplicated copy of the same dependency patch.

---

LGTM。本 PR 将 CoPaw/MCP 兼容性热修复独立成了范围清晰的依赖 PR。copaw-worker 构建日志确认两条安装路径最终都使用 mcp 1.29.1，此前受影响的集成测试分片也已全部恢复绿色。

本 PR 合并后，#1208–#1212 应进行 rebase，并删除其中重复携带的相同依赖 patch。

[LUOSENGWA]

@shiyiyue1102 Thanks for merging — that unblocks the whole batch.

Per your note, I've rebased all in-flight PRs onto the new main (ac22c887). The rebase was clean (zero conflicts) and the duplicated mcp>=1, <2 patch no longer exists in any branch. CI re-ran after the rebase:

• ✅ fully green (all shards): feat(controller): add team-scoped worker knowledge base file endpoints (+ checkpoint scoped-access fix) #1208, feat(controller): add human update endpoint (PUT /api/v1/humans/{name}) #1209, feat(controller): add read-only skill catalog endpoint for workbench #1211, feat(controller): allow L2 humans to update worker skills within their teams #1212, fix(controller): checkpoint proxy scoped check compared member name as team name #1214, feat(controller): add team-scoped worker tool approval endpoints for L2 humans #1216, feat(controller): add worker channel configuration proxy endpoints #1219 (draft)
• ⚠️ fix(controller): grant Matrix power levels to human members on room join #1210: green except one known-flaky test — test-23-runtime-switch (SHARD_C, qwenpaw×qwenpaw) failed on the test's fixed 60s wait for CoPaw→MinIO state persistence. The same test passed on the other three runtime combos in the same CI run and on all seven sibling PRs, and fix(controller): grant Matrix power levels to human members on room join #1210's diff (Matrix room power levels) doesn't touch that path, so I read it as a timing flake rather than a regression. I don't have re-run permission — could you re-run just that one failed job?
• ⏳ feat(taskflow): emit code-level completion notification on task submission #1206: waiting on CI approval.

The remaining PRs are ready for review whenever you have time. Suggested order (fewest cross-PR conflicts first): #1208 → #1210 → #1212 → #1211 → #1209; #1214 / #1216 / #1219 are independent.

谢谢合并，解锁了整批。

按你的提示，所有在飞 PR 已 rebase 到新 main（ac22c887），零冲突，重复的 mcp>=1, <2 patch 已不再存在于任何分支。rebase 后 CI 已重跑：

• ✅ 全绿（全 shard）：feat(controller): add team-scoped worker knowledge base file endpoints (+ checkpoint scoped-access fix) #1208、feat(controller): add human update endpoint (PUT /api/v1/humans/{name}) #1209、feat(controller): add read-only skill catalog endpoint for workbench #1211、feat(controller): allow L2 humans to update worker skills within their teams #1212、fix(controller): checkpoint proxy scoped check compared member name as team name #1214、feat(controller): add team-scoped worker tool approval endpoints for L2 humans #1216、feat(controller): add worker channel configuration proxy endpoints #1219（draft）
• ⚠️ fix(controller): grant Matrix power levels to human members on room join #1210：除一个已知 flaky 测试外全绿——test-23-runtime-switch（SHARD_C，qwenpaw×qwenpaw）挂在测试自身的固定 60s「CoPaw→MinIO 状态持久化」等待上。同一测试在同一次 CI run 的另外三个 runtime 组合、以及全部 7 个兄弟 PR 上都是绿的，且 fix(controller): grant Matrix power levels to human members on room join #1210 的 diff（Matrix 房间权限）不触碰该路径，判定为时序 flake 而非回归。我没有 re-run 权限，能否帮忙只重跑这一个失败的 job？
• ⏳ feat(taskflow): emit code-level completion notification on task submission #1206：等 CI 审批。

其余 PR 已可 review，建议顺序（跨 PR 冲突少优先）：#1208 → #1210 → #1212 → #1211 → #1209；#1214 / #1216 / #1219 独立。