[Ideas] Two small upstream improvements: plugin-exposed settings namespaces + Chinese-friendly model errors

[Semidia]

Two small upstream improvements that community plugins currently work around with local patches. Since external PRs are not accepted at the moment, posting here for the team's consideration (upvote if useful).

1. Let a plugin expose its own settings namespace

packages/host/apiproxy/src/api-proxy.ts serves only namespaces on the hard-coded WEB_SETTINGS_NAMESPACES allowlist to configuration clients. A plugin (e.g. our dsh-sampling-sliders) that registers a namespace via the settings seam gets settings-not-exposed on every browser write. The code comment already marks "moving that declaration to settings.register()" as deferred work - this is a small step in that direction (allowlist addition, or an explicit expose option on register()).

2. Chinese-friendly, actionable model failure copy

displayFailureMessage (packages/client/runtime) currently projects raw English provider text (e.g. "Insufficient Balance") into the GUI. A code-to-copy map (QUOTA / RATE_LIMIT / AUTH / TIMEOUT / TRANSPORT / CONTEXT_WINDOW_EXCEEDED / SERVER ...) with concrete suggestions, plus an expandable raw-detail fold in the turn-error card, makes failures actionable. The harness already classifies failures into stable codes, so no free-text parsing is needed.

Implementation is ready on fork branches:

• https://github.com/Semidia/deepseek-harness/tree/feat/apiproxy-expose-sampling-sliders
• https://github.com/Semidia/deepseek-harness/tree/feat/error-zh-runtime
• https://github.com/Semidia/deepseek-harness/tree/feat/error-zh-ui-conversation

Both improvements are already usable today as community plugins:

• dsh-sampling-sliders: https://github.com/Semidia/dsh-sampling-sliders
• dsh-friendly-errors: https://github.com/Semidia/dsh-friendly-errors

[Semidia]

Update: a third community plugin hit the same wall. dsh-smart-route (provider auto-routing with fallback to the next channel on any error, incl. 4xx) registers its smart-route settings namespace for its settings card and composer toggle. Because the namespace is not on the WEB_SETTINGS_NAMESPACES allowlist, settings.describe omits it, the client settingsScope stays unavailable, and the settings card is stuck on its loading state forever. In this case the host half never even registered: a required() field in the plugin Config made apply throw first when the composition provided no config, so the namespace was absent from the registry entirely. Both local fixes (allowlist entry / a schema default) are stopgaps; the deferred work already noted in the apiproxy source - moving the exposure declaration to settings.register() - is exactly what would make plugin-owned settings namespaces work out of the box.