Host capability: graceful self-restart for plugin managers

[fkysly]

Problem

A plugin that manages plugins (marketplace / updater) can complete an install or update on disk, but cannot activate it:

• New plugins we can hot-mount into the running composition (an Include subtree with write() suppressed — the agent-presets PresetTree pattern — plus a boot-time input wipe; works well in practice, verified against restart collisions).
• Updates to already-loaded code are the hard wall: the old module is in the ESM cache and its fibers hold live registrations. There is no supported way to re-import a changed module, and cache-busting specifiers would create duplicate module instances (duplicate cordis service identities). So every update flow ends with "please restart DeepSeek Harness yourself", which is the single worst step in an otherwise click-only experience.

oh-dsh's desktop app solves this from outside the runtime (its Electron main process stops and relaunches the composition). An in-process plugin has no equivalent.

Proposal

A host capability for a graceful self-restart, e.g.:

ctx.appLifecycle.requestRestart(reason: string): void

• drains in-flight work, disposes the root, then re-execs the same argv (process.execPath + process.argv), or exits with a documented code so a supervisor/launcher re-runs it;
• gated like other privileged capabilities (a profile/composition opt-in seems right — a marketplace bundle would declare it, a headless run would not compose it);
• web client reconnect already handles the brief gap (the HMR receiver survives worse).

With this, "install → live immediately; update → one confirmation, seconds of downtime, no terminal" becomes possible for out-of-tree managers.

Context: dsh-market; happy to contribute the implementation against maintainer guidance.