chore(acp): update DeepSeek runtime and SDK

[agentconnect-md-test]

The Cloud runtime image still installs DeepSeek Harness ACP 0.4.36 after 0.4.37 was published, and the daemon lockfile still resolves ACP SDK 1.5.1 after 1.7.0 was published. This PR updates the runtime pin and refreshes the daemon's SDK dependency and lockfile.

Runtime interface comparison (0.4.36 → 0.4.37):

• The executable remains dsh-acp.
• Permission mode IDs (read-only, workspace-write, danger-full-access) and live provider/model ID construction are unchanged in the published package diff.
• 0.4.37 newly advertises ACP session/fork and JetBrains Air's inclusive fork extension.

The other monitored runtime pins are current: Claude ACP 0.85.1, the published AgentConnect Codex fork 2.1.1-agentconnect.1 (upstream stable 2.1.1), agent-browser 0.38.2, and pi-acp 0.0.34. ACP SDK 1.7.0 keeps the stable v1 entry point; its intervening releases update the schema, fix a connection type, and refine experimental v2 validation.

Validation: installed both DeepSeek versions in isolated directories and probed ACP initialize; both answered with the expected version, and only the new version advertised fork. session/new returned auth-required under clean credentials, so the mode/model comparison uses the published package diff. The pnpm-generated lockfile changes only the SDK resolution, and git diff --check passed. Local daemon typecheck and Docker image build could not run: this runner has no Docker daemon, and the workspace dependency install was killed with exit 137 while materializing packages. CI should run those checks on the PR.

Created by Codex . GPT-6

[agentconnect-md-test]

Passes, no blocking findings. I'm posting this as a comment because GitHub refused the APPROVE with a 422. That usually means the reviewing account also opened the PR.

This changes one line: the version of @openma/deepseek-harness-acp pinned in docker/runtime-sandbox.Dockerfile goes from 0.4.36 to 0.4.37.

What I checked:

• The DEEPSEEK_HARNESS_ACP_VERSION default is set in one place only. The later ARG lines in the Dockerfile and install-core-harnesses.sh take it from there, so no other copy needs updating.
• The PR says 0.4.37 now advertises ACP session/fork. The daemon doesn't use that: acp-host.ts only reads the additionalDirectories and delete session capabilities. So existing sessions are unaffected.
• According to the PR, the dsh-acp bin name, the permission mode IDs and how provider/model IDs are built are unchanged. Those are what the daemon's DeepSeek preset and probe code relies on, so I don't see a compatibility risk.

Not blocking: the image build wasn't run locally because there was no Docker daemon. The next runtime-image CI build will confirm that the package installs.

_{sent by review-bot (Claude Agent · opus) · open in session}

[agentconnect-md-test]

Passes at 94dd4fb, no blocking findings. I'm posting this as a comment because GitHub refused the APPROVE with a 422 again. That usually means the reviewing account also opened the PR, so a person needs to give the formal approval.

DeepSeek Harness ACP 0.4.36 → 0.4.37 (docker/runtime-sandbox.Dockerfile): same as the previous revision. The version default is set in one place only. The daemon never reads the session/fork capability that 0.4.37 adds (acp-host.ts reads only additionalDirectories and delete), so existing sessions are unaffected.

New in this revision: @agentclientprotocol/sdk ^1.5.1 → ^1.7.0 (daemon + lockfile). I diffed the two published packages against what the daemon imports:

• Runtime JS: acp.js changes only one re-export (StateUpdate), and protocol-router.js changes only a doc comment. The client, methods and ndJsonStream behavior the daemon uses is the same.
• Removed: methods.mcp_connect / mcp_disconnect and the ConnectMcp* / DisconnectMcp* / McpConnectionId types (the unstable MCP-over-ACP surface). Nothing in packages/daemon/src uses them.
• Added only: three new SessionUpdate kinds (session_message, session_message_chunk, subagent_update), plus state, subagent and session-cancel capability types. None of the types the daemon imports lost a field.
• Only the daemon depends on the SDK. The lockfile drops the 1.5.1 entry with nothing else still pointing at it.

Not blocking: when I reviewed, CI (Build · Check / Unit Test / Windows) was still running on this head. Any exhaustive switch on SessionUpdate that now sees the new kinds will show up in typecheck there. The image build still hasn't run locally.

_{sent by review-bot (Claude Agent · opus) · open in session}