v0.3.1 — dual-engine settings compatibility (dsh 0.1.5 → 0.2.0)

dsh-image-plugins 0.3.1 — dual-engine settings compatibility

One build now works across the dsh settings rewrite (0.1.5 → 0.1.7 → 0.2.0).

dsh 0.1.7 replaced the settings subsystem: the host dropped SettingsProvider.installSection(), the browser dropped the settingsScope service, and live-editable schema fields must be declared volatile. Against those hosts 0.3.0 crashed on load and its settings panel never rendered. 0.3.1 adapts at runtime instead of pinning a host version.

Fixed

• Host, dsh ≥ 0.1.7 / 0.2.0 — plugin load no longer throws settings.installSection is not a function. The new installSettingsCompat duck-types the host: installSection on ≤ 0.1.5, SettingsForms.configure({ auto: false }) plus an app-boot/config-reload listener on ≥ 0.1.7.
• Browser, dsh ≥ 0.1.7 / 0.2.0 — the settings panel no longer hangs. settingsScope is gone from the static inject list (declaring a service the host deleted blocks plugin activation entirely); the scope is resolved at runtime from configForms.get('image-plugins'), falling back to settingsScope.bind({ namespace: 'dsh-image-plugins' }) on older hosts.
• Schema — every editable field is marked volatile in the form hosts read it (meta.volatile, via .extra('volatile', true): schemastery 3.18.x ships no .volatile() method). Without it, 0.1.7+ hosts reject a live edit with Config field "…" is not volatile.

Verified hosts

Host	Settings path exercised
0.1.5-rc.x	installSection + settingsScope
0.1.7-rc.2	SettingsForms.configure + configForms
0.2.0-rc.2	same as 0.1.7 — confirmed by unpacking the host's own @deepseek-ai/dsh-settings, dsh-client-ui-settings, dsh-client-connection and dsh-credentials-local to check configure, meta.volatile, configForms.get, and the /api Fetch route registry

Changed

• peerDependencies widened to >=0.1.2-rc.1 so the 0.1.7+ compatibility pre-check accepts the plugin.
• Tests: 73 (was 69). Added tests/client.test.ts (classic-script evaluation plus both scope-resolution branches) and a 0.1.7 SettingsForms boot test asserting configure({ auto: false }) and config-reload behaviour.

Notes

• Where the panel persists edits follows the host: ~/.dsh/settings.yaml on ≤ 0.1.5; on ≥ 0.1.7 that global file is retired (archived as settings.yaml.imported) and edits land in the profile's cordis.patch.yml under the image-plugins entry. Secret values always live in ~/.dsh/.credentials.yaml.
• Unchanged from 0.3.0: per-capability enable switches for understand_image / generate_image, and the /api/image-plugin-status/snapshot status route.

Full changelog: v0.3.0...v0.3.1