fix: declare dsh 0.2.x compatibility so 0.2.1 installs and boots

[helloHub1212]

Description（描述）

@deeptrial/dsh-bash-rtk@0.1.1 无法安装在 dsh 0.2.1-alpha.1 上：harness 的安装门禁把它判为不兼容并
直接拒绝，插件根本没有机会加载。

根因在「声明的兼容性元数据」，而不是运行时的执行接缝：

• @deepseek-ai/dsh-app-boot 的 evaluatePluginCompatibility() 会读取插件的 peerDependencies，
  对其中每个 @deepseek-ai/dsh / @deepseek-ai/dsh-* 条目，用当前正在运行的 dsh 版本执行
  semver.satisfies(runtime, range, { includePrerelease: true }) 校验。本插件的三个 peer 范围上限都停在
  <0.2.0-0，因此没有任何一个能满足 0.2.1-alpha.1。
• 插件市场（dshmarket）采用同样的「预发布感知」判定，并且读的是顶层 engines.dsh（或
  dsh.engines.dsh）加上同一批宿主 peer。本插件的 package.json 里这两个位置都没有声明
  （范围只写在非标准的 dsh.plugin.json 中，而 dsh 0.2.1 不读取该文件），所以市场侧同样报「不兼容」。

值得说明的是：0.2 并没有改动执行接缝——插件依然只覆写 resolve()，0.2 的 ShellExecSpec 只是多了
一个 sandboxPolicy 字段，而它是被原样展开透传的。

Reproduction（复现步骤）

1. 使用 dsh 0.2.1-alpha.1（例如 npx @deepseek-ai/dsh@0.2.1-alpha.1 --profile web）。
2. 执行 dsh plugin --profile web add @deeptrial/dsh-bash-rtk@0.1.1（或通过插件市场安装）。
3. 安装被拒绝。

Expected Behavior（期望行为）

插件安装成功，它的 bundle patch 正常生效；启用 bash-rtk 后注册为 ctx.shell。

Actual Behavior（实际行为）

dsh: installation rejected: Plugin @deeptrial/dsh-bash-rtk@0.1.1 is incompatible with dsh 0.2.1-alpha.1:
peerDependencies {"@deepseek-ai/dsh-bash-local":"0.0.1-rc.1","@deepseek-ai/dsh-bash-sandbox":"0.0.1-rc.1","@deepseek-ai/dsh-shell":"0.0.1-rc.5"}.
Running it may cause crashes or data loss. Update the plugin or install a plugin version compatible with this dsh runtime.
To accept this risk explicitly, grant the exact-version exemption ... Exact-version exemption: not active.
dsh: nothing was installed.

Environment（环境）

• Node.js version: v26.10.0（上游 CI 的 22.19 表现相同）
• dsh-bash-rtk version: 0.1.1（复现）→ 0.1.2（修复后）
• dsh version: 0.2.1-alpha.1
• rtk version: rtk 0.50.0
• OS: CachyOS / Linux 7.2.8

这个 PR 改了什么

一共三个部分；0001 + 0002 是真正的修复，0003 是构建/开发工具链的改造建议，去掉它不影响修复效果
（见文末说明）。按补丁方式提交时它们就是三个提交；如果用网页上传文件，则这三部分会落在同一个提交里。

0001 —— 声明 dsh 0.2.x 支持

• 三个宿主 peer 各追加一个显式的 0.2.x 分支：… || >=0.2.0-0 <0.3.0-0
  （原有的 0.0.1 / 0.1.0 / 0.1.1 分支一个字都没动）。
• 在 package.json 里新增 engines.dsh: ">=0.1.0-rc.6 <0.2.0 || >=0.2.0-0 <0.3.0-0"
  —— 这是发现类工具真正读取的位置。
• dsh.plugin.json 里镜像同一范围；插件版本升到 0.1.2。

0002 —— 改用 @deepseek-ai/cordis 并适配 0.2 的 shell 接口

• src/index.ts：import { Context } from 'cordis' → '@deepseek-ai/cordis'
  （纯类型导入，构建后会被擦除；产出的 lib/ 依然只 import dsh-bash-local / dsh-bash-sandbox）。
  tsdown.config.ts 的 neverBundle 同步修改。
• tests/*：run() → execute() + result()；SandboxProvider.confine() 改为 async；为
  SandboxPolicyService 注册 SessionProjectionRegistry；新增一条覆盖 execute()/result() 契约的
  端到端测试。

0003 —— 构建与文档改为面向已发布的 0.2.1 包

• devDependencies：把 link:../deepseek-harness/... 换成已发布的 0.2.1-alpha.1 包
  （外加 @deepseek-ai/cordis、schemastery、dsh-session-projection），仓库可以独立构建；
  同时重新生成 pnpm-lock.yaml。
• CI：去掉「克隆同级 harness + build:lib:host」两步，保留
  pnpm install --ignore-scripts + pnpm run check。
• README / README.zh：重写兼容性章节（门禁语义、预发布分支、engines.dsh）与开发章节。

说明：.github/workflows/ci.yml 的更新属于可选项。GitHub 规定修改工作流文件需要凭据具备
workflow 权限，否则 API 会以 404（而不是 403）拒绝；因此本 PR 可以只带上面 9 个文件、
不含该工作流改动 —— 这不影响修复本身，也不影响仓库能否构建。

Verification（验证记录）

• 修复后的树跑 pnpm run check：tsc 无报错、30/30 测试通过、tsdown 构建成功。
• 安装门禁：直接调用 harness 真实的 evaluatePluginCompatibility()（来自
  @deepseek-ai/dsh-app-boot），在运行时 0.2.1-alpha.1 下校验修复后的 manifest → 无任何不兼容 peer。
  用同一函数校验 0.1.1 的 manifest，则逐字复现上面的报错。
• 插件市场：dshmarket 的 deriveHostCompatibility() 对修复后的 manifest 返回 compatible
  （修复前是 incompatible）。
• 真实启动：把打包好的 tarball 装进一个隔离的 DSH_HOME profile
  （dsh plugin --profile rtktest add …，安装被接受、无任何拒绝），关闭 bash-sandbox、启用
  bash-rtk 后启动 dsh 0.2.1-alpha.1。带探针的构建确认：模块成功加载、@deepseek-ai/dsh-bash-local
  解析到 harness 安装目录（不存在重复实例）、RtkSandboxBashExecutor 被构造并注册为 ctx.shell。
• 真实 profile 端到端（上报问题的机器，dsh 0.2.1-alpha.1 + rtk 0.50.0）：修复后
  dsh plugin --profile web add 能接受插件（0.1.1 会被拒绝）；在 profile patch 中启用 bash-rtk 后，
  再通过 bash 工具执行命令可观察到：git status 的输出与 rtk git status 完全一致，而
  command git status 与 git status | cat 仍走原生 git 路径（白名单守卫与复杂命令守卫都正常），
  git rev-parse HEAD 与未包装时结果一致，失败命令仍正确上报 [exit code: 128]。
• 向后兼容：把修复后的构建加载到完整的 dsh 0.1.1-rc.2 运行环境
  （@deepseek-ai/cordis@4.0.1 + 0.1.1-rc.2 的 shell 包）上验证：两个执行器都能注册、都能包装
  符合条件的命令（rtk git status）、复杂命令照旧透传、通过旧版 run() 接口执行成功、沙箱事实
  正常上报。peer 范围只是新增分支，因此不存在「原本兼容的版本反而变得不兼容」的情况。

Additional Context（补充说明）

• 这种「按发布线逐条写分支」的写法是刻意的：按 node-semver 的默认规则，一个宽范围
  >=0.0.1-rc.1 <0.3.0 会静默排除所有 0.1.x / 0.2.x 预发布版本。而 dsh 的门禁与市场都用
  includePrerelease: true 求值，这正是上面那些显式 <0.x.0-0 上界能够生效的原因。
• 关于第 0003 部分（构建/CI/文档）：它只是「顺手改善」，不属于修复本身。如果维护者希望保留原先
  link:../deepseek-harness/... 的开发流程与 CI，可以只回退 devDependencies + pnpm-lock.yaml
  相关改动；保留 0001 + 0002 两部分就足以支持 0.2.1（两种组合我都验证过可以干净地应用到 main 上）。
• 修复要真正惠及市场 / registry 用户，需要发布一个新版本，因为发现逻辑读的是已发布的 manifest。