fix(manifest): support DSH 0.2.x — 0.2.0 currently rejects the whole bundle

[rezon-aki]

Summary

The plugin declares its @deepseek-ai/dsh-client-* peers as >=0.1.0-rc.6 <0.2.0. DSH's startup gate (evaluatePluginCompatibility in dsh-app-boot) matches peer ranges with includePrerelease: true, so 0.2.0-rc.x passes — but 0.2.0 and every later release fail. A rejected bundle is skipped whole: the indicator, the panel and all five routes disappear, and the only trace is one pluginCompatibilityWarning line on dsh web's stderr. Typecheck, build and the existing tests stay green, so nothing in CI catches it.

• Peer ranges for dsh-client-locale, dsh-client-ui-conversation and dsh-client-ui-slots now cover both lines: >=0.1.0-rc.6 <0.2.0 || >=0.2.0-rc.1 <0.3.0.
• Dropped @deepseek-ai/dsh-client-runtime from peerDependencies, peerDependenciesMeta and dsh.client.inject: it no longer exists in DSH 0.2.0, and this plugin only imported it as a type (erased at build time). @deepseek-ai/dsh-client-web-react and @deepseek-ai/dsh-client-schema-form were removed from the client externals for the same reason.
• tests/manifest.test.mjs now asserts the shape of the declarations instead of pinning the old literal range; the range semantics are covered by the new test below.
• New tests/dsh-compat.test.mjs calls DSH's own evaluatePluginCompatibility against this manifest for a version matrix (0.1.x, 0.2.0-rc.x, 0.2.0 and 0.2.1), asserts the undeclared 0.3.0 line is still rejected, and checks that every DSH package the manifest names really exists in the target DSH.

Verification

• npm run verify — 49/49 (46 existing + 3 new compatibility assertions)
• npm pack --dry-run
• Clean-profile DSH installation tested when bundle, inject, slot, or route behavior changed
• No API keys, account data, private sessions, logs, or generated lib/ files included
• CHANGELOG.md updated for user-visible changes

The compatibility claim is checked by calling DSH's gate function rather than by eyeballing the range. Note: #17 (draggable panel) also adds an ## [Unreleased] block to both CHANGELOGs, so those two files will conflict when both land — happy to rebase whichever one is merged second.

[Max-Samson]

Reviewed at 7650147. The manifest change is directionally correct: I independently ran the evaluatePluginCompatibility implementation from upstream DSH 0.2.0-rc.2 against the declared matrix; 0.2.0 and 0.2.1 are accepted, and 0.3.0 is rejected. The removed packages have no value imports in this plugin, and the built browser bundle only requires react/react-jsx-runtime.

Local npm run verify reports 49 tests, but only 46 pass and the 3 new compatibility tests are skipped. npm pack --dry-run passes. Please address the CI coverage gap below and provide the clean-profile installation smoke test required by CONTRIBUTING.md for inject/module-loader changes before treating this as end-to-end 0.2.x compatibility verification. I have not verified a full live DSH installation.

[Max-Samson]

[P2] Ensure the compatibility regression is actually exercised in CI

The current CI workflow installs only this plugin and supplies no DSH_CHECKOUT, so all three new compatibility tests always skip. At the same time, manifest.test.mjs removes the existing literal-range assertion. Reintroducing the old '<0.2.0' upper bound would therefore still produce a green standard CI run. Locally, npm run verify reports 46 passed / 3 skipped; explicitly setting DSH_CHECKOUT to a nonexistent directory also silently skips because loadDsh catches every resolution/import failure.

Please keep an unconditional range-semantics regression test or wire a pinned DSH installation into CI so these checks run. When DSH_CHECKOUT is explicitly supplied, a broken checkout/import should fail the test instead of being treated as an absent optional environment.