fix: 避免重复安装 DSH 宿主运行时依赖

[wang-kaopu]

修改内容

• 将 DSH 宿主运行时依赖从 dependencies 移到 devDependencies
• 保留 @deepseek-ai/schemastery 作为运行时依赖
• 增加回归测试，防止宿主依赖再次被加入 dependencies

问题原因

安装插件后会额外安装一份 DSH 宿主运行时包，包括 @deepseek-ai/dsh-tools。

由于 TOOL_RUNTIME_SCHEDULER 使用模块实例相关的 Symbol()，宿主与插件加载不同物理路径下的 dsh-tools 后，两边的 Symbol 身份不同，最终导致工具执行阶段无法获取调度器，并出现：

Cannot read properties of undefined (reading 'prepare')

本次修改通过避免插件安装独立的 DSH 宿主运行时副本来解决该问题。

验证

• npm test：通过
  • 8 个 smoke checks
  • 7 个 tool checks
• npm pack --dry-run：通过

Fixes #2

[AINightCoder]

Independent reproduction, and a suggestion on the declaration style.

Reproduction

Hit the same bug from a different angle before finding this PR: DSH 0.1.0-rc.7 (host packages resolving at rc.8), pnpm 11, Windows, on a dsh-tui profile rather than Web. Same failure, same mechanism, and it reproduced under both the stock standard preset and a custom one, so it is not preset-specific.

What isolated it here was an asymmetry between two profiles on the same machine:

profile	local @deepseek-ai/dsh-tools	tool calls
web	absent (this profile happened to resolve without it)	work
dsh-tui	present, shadows the flat fallback	fail, every call

Both profiles ran byte-identical dsh-tools, with scheduler.prepare on the same line. Only the presence of the duplicate tracked the failure, which is what ruled out version drift. Removing the profile-local copy by hand fixed it immediately. So: confirming your diagnosis from a second environment.

Suggestion: peerDependencies rather than devDependencies

Both stop the duplicate from being installed, so this is not a correctness argument. The reason to prefer peers here is that it costs nothing extra in a DSH profile: DSH writes the setting into every profile template itself, so peers are never auto-installed.

dsh-app-boot/lib/index.js:344            autoInstallPeers: false
~/.dsh/profiles/<name>/pnpm-workspace.yaml   autoInstallPeers: false

With that guaranteed, peerDependencies has the same install behaviour as devDependencies and additionally declares which host version the plugin expects, which devDependencies communicates to consumers not at all.

That contract is worth something concretely. The other two commits in #4 fix a silent rc.6 → rc.7 client-face breakage in this plugin: dsh.client.inject named @deepseek-ai/dsh-client-ui-slots, which rc.7 removed. An unresolvable module name stops the client bundle from being served, so the host rows still reported Mounted, Enabled, the settings panel never rendered, and nothing was logged to the console. A declared peer range would have surfaced that at install time instead. For reference, @deepseek-harness-tui/dsh-tui declares its 24 host packages as peers for the same reason, and prints an explicit drift warning per package when the resolved version differs from the validated one.

If that seems reasonable it is a small edit on top of this PR, and your regression test could assert the peer block is present in addition to asserting the packages stay out of dependencies. Happy either way, this PR came first and fixes the bug.

I have the same manifest change sitting on my branch in #4 purely because my own install depends on it; it should be dropped in favour of whatever lands here.