deepseek-harness-runtime-bin: include @deepseek-ai/dsh-mcp-client in the deploy-root closure

[jiaoqsh]

Summary

The Python SDK's bundled runtime cannot mount MCP servers: the deploy root
(python/sdk-runtime/package.json, whose dependency closure IS both the exe's
plugin set and the node carrier's tree) does not list
@deepseek-ai/dsh-mcp-client. packaged-bin.js resolves bare plugins only from
that closed tree, so any Cordis composition carrying an mcp-client row fails to
load on both bundled carriers — and MCP is the standard way for a host
application to hand its own tools to the agent.

The sdk-runtime README
describes exactly the intended fix path:

Adding a plugin to the distribution means adding one dependency line there and rebuilding.

Why it matters

For an embedder, the SDK runtime without an MCP client is an agent that can only
use the plugins baked at build time — no host-provided tools at all. We currently
work around this by maintaining our own npm deploy-root closure (same
packaged-bin.js, our own package.json with the extra line), which works but
means the official wheels are unusable for any MCP-carrying composition.

dsh-mcp-client is already published to npm at the same 0.1.0-rc.x wave as
the rest of the runtime, so this appears to be exactly the advertised
one-line-plus-rebuild change.

Ask

Add "@deepseek-ai/dsh-mcp-client" to python/sdk-runtime/package.json's
dependencies and include it in the next runtime wheel build. A composition that
doesn't reference it pays nothing; one that does currently cannot boot at all on
the bundled carriers.

Environment

deepseek-harness-sdk / deepseek-harness-runtime-bin 0.1.0rc6 (PyPI);
verified against the npm-published 0.1.0-rc.6 packages that an mcp-client row
loads and serves mcp__<server>__<tool> tools once the package is present in
the closure.

[kunwar-vp]

Independently hit this and can corroborate the exact fix proposed here: added the one line to python/sdk-runtime/package.json, verify-runtime-closure passes (closed graph, 110 packages), and the rebuilt node-mode runtime runs a composition with dsh-llm-pi-ai (custom provider route) + dsh-mcp-client (stdio server, ~96 tools) + dsh-tool-fs end to end through the Python SDK — tools discovered, registered, and called by the model. Until it ships in the wheel, every MCP-carrying embedder has to maintain this same one-line fork. Fuller writeup of how this interacts with the boot race in #2273.

[zoahdev]

This is the same deploy-root omission as #2273 — a branch already exists with the exact one-line fix.

• Branch: zoahdev/deepseek-harness@fix/sdk-runtime-mcp-client-closure (cherry-pick-ready against 47f943859b)
• python/sdk-runtime/package.json: @deepseek-ai/dsh-mcp-client: workspace:^ added (with the lockfile), exactly the diff this thread proposes.
• Verified: verify-runtime-closure passes (110 workspace packages, closed graph).

Cross-refs: #2273 / #1240 / #2115 all report the same dsh-mcp-client missing from the runtime closure; this one branch closes all three. A composition that doesn't reference it pays nothing, and one that does now boots on the bundled carrier.