fix!: port the settings page and shell seam to dsh 0.1.7-rc.2

0.1.7-rc.2 moved four things this bundle was built on, and every one of them
failed quietly rather than loudly, so the plugin looked installed and did
nothing:

  * `ctx.settings.installSection(...)` is gone. The call threw into a
    `try/catch` that only logged a warning, so the settings namespace was never
    registered and `configure` had nowhere to persist. An entry's exported
    Config IS the form now; the namespace is the Loader entry id the bundle's
    patch declares, and `ctx.settings.configure({ auto: false })` is what claims
    that entry's own page.

  * `settingsScope` and the `settings.plugin.item` slot are gone. The card
    registered into both, so it never rendered — the tab draws the intersection
    of served namespaces and registered cards, and that intersection was empty.
    It now registers into `plugins.bundle.config` keyed by the bundle's package
    name, over the `configForms` service, and uses the framework's own form
    chrome (`SettingsFormModel` / `SettingsForm` / `SettingsValueField` /
    `SettingsSecretField`) instead of the hand-rolled equivalent. A save is one
    revision-fenced write.

  * `ctx.shell.run(spec)` is gone. Every action that runs a command threw
    `shell.run is not a function`; the seam is now
    `await ctx.shell.execute(ctx.shell.resolve(request)).result()`.

  * A job's `owner` is a session id, not the agent object. The wrong owner
    registered a job no session could collect or cancel, and the producer's
    `done` resolved `output` where the registry reads `result`, so a finished
    job handed back nothing.

Two conformance gaps went with them: a Config field that is not marked
`volatile()` is invisible to every settings UI — the form projection keeps only
volatile fields, and an entry with no form is dropped from `settings.describe`
entirely — and `embeddingApiKey` was a plain field, so the key rode every
settings read back to the browser. It is `role('secret')` now: the browser is
told whether a key is stored and never receives the key.

Also declares the `@deepseek-ai/dsh-*` peerDependencies the compatibility gate
reads, so an incompatible runtime refuses this plugin at startup instead of
half-loading it.

Verified against a real 0.1.7-rc.2 boot: `settings.describe` serves the entry
with `autoGenerate: false`, the key redacted and reported only as `set: true`,
and no startup diagnostics. The host mock in the tests now has no `run` and no
`installSection`, so those seams are contract-tested rather than assumed, and
the browser tests read the installed harness's own slot catalog and package
exports — a rename fails a test instead of quietly emptying a page.

cordis.patch.yml

@@ -4,8 +4,10 @@
 #   * three skills on `ctx.skills`, all user-invocable and NOT model-invocable
 #     (slopo's own agent configs make the same choice, because every one of
 #     these commands can spend minutes embedding);
-#   * a configuration namespace on `ctx.settings`, so the embedding backend is
-#     editable at runtime rather than baked into this file;
+#   * the `dsh-slopo` configuration, which is this plugin's own exported Config:
+#     since dsh 0.1.7-rc.2 the framework projects that schema onto this entry and
+#     addresses it by `id`, which is why the id below is also the browser card's
+#     slot key. It is editable at runtime rather than baked into this file;
 #   * one `slopo` tool that resolves the CLI, runs it, and streams progress.
 #
 # The row references the package by NAME rather than a relative path, so Node
@@ -13,9 +15,10 @@
 #
 # There is deliberately NO `config:` block here. Every value the plugin needs is
 # either discovered at runtime (the slopo binary), set by the user through the
-# settings namespace, or genuinely optional. Shipping defaults would mean baking
-# one machine's paths into a layer that other machines also apply, and the
-# plugin's own schema already carries the defaults it can honestly claim.
+# settings card or the tool's `configure` action, or genuinely optional. Shipping
+# defaults would mean baking one machine's paths into a layer that other machines
+# also apply, and the plugin's own schema already carries the defaults it can
+# honestly claim.
 
 - insert:
     - id: dsh-slopo