fix: keep rc.6 UI plugins compatible with keyed settings slots

[Yj-30422]

Summary

• translate an rc.6-style id into the rc.7 key only for the keyed settings.plugin.item slot, while keeping explicit keys authoritative
• keep normalized legacy, self-contained settings cards visible without relaxing namespace checks for modern key-only cards
• install the same narrow shim into the minified SlotCore bundle actually served by DSH Desktop, with idempotence and fail-loud vendor-drift checks
• add regression coverage for legacy registration, disposal, collisions, unrelated keyed slots, settings dispatch, postinstall wiring, and the served frontend asset

Root cause

Harness rc.6 exposed settings.plugin.item as a list slot, so existing third-party bundles register an id. rc.7 changed that slot to keyed and now requires options.key, causing those bundles to fail during UI startup before the desktop can render.

The browser shell bundles its own SlotCore inside @deepseek-ai/dsh-web-frontend/dist, while client plugins are served dynamically from their package bundles. The fix therefore covers both runtime paths rather than patching only the import used by tests.

Fixes #74.
Related to #69.

Verification

• clean dependency install with scripts skipped, followed by patch-package --error-on-fail
• compatibility installer executed twice successfully to verify idempotence
• npm test — 17 files, 86 tests passed
• npm run typecheck
• npm run build
• node --check on the actual served frontend asset
• git diff --cached --check

Limitations

A packaged Electron visual launch was not performed because the Electron binary was intentionally not downloaded in this environment. The main/preload production build and runtime asset syntax checks passed. The frontend rewrite deliberately fails installation if a future Harness asset no longer matches the pinned rc.7 shape, so an upgrade cannot silently omit the compatibility shim.