Allow third-party plugins to expose their own settings namespaces to the Web plugin-configuration section

[HsiangNianian]

Summary

The Web plugin-configuration section (设置 → 插件配置, served by dsh-host-apiproxy) only exposes settings namespaces listed in the hardcoded WEB_SETTINGS_NAMESPACES allowlist. A third-party plugin can register a namespace via ctx.settings.register(...) (it persists fine), but the browser half gets settings-not-exposed from settings.describe, so its settings card renders nothing and users cannot configure the plugin from the GUI.

The code comment in dsh-host-apiproxy already acknowledges this:

a namespace absent here answers settings-not-exposed even when its owner registered it, so adding a section to that page is a decision made here rather than by the registering plugin. Moving that declaration to settings.register(), so a plugin can expose its own configuration without a change in this package, is deferred work.

Proposal

Move the exposure decision into settings.register() so a plugin can opt in:

ctx.settings.register(settingsNamespace('my-plugin'), schema, {
  applies: 'live',
  expose: true, // opt-in: serve this namespace to configuration clients
});

Keep the allowlist as the default for existing namespaces (backwards compatible), and let exposedNamespaces() include every namespace registered with expose: true (probably gated on the owner being an enabled entry, like the current explicit list). A restart-applies namespace could be excluded from the exposed set if that is safer.

Context

I maintain a third-party plugin (dsh-auto-continue) that registers an auto-continue settings namespace. Without this change, every installation needs a one-time vendor patch that appends the namespace to WEB_SETTINGS_NAMESPACES in the installed bundle (see scripts/patch-expose.mjs) — it works but is fragile across reinstalls (npx cache, global installs) and is exactly the kind of per-plugin core modification the seam was meant to avoid.

Happy to adapt the proposal or submit a PR if that helps.