Desktop shell copy (welcome window, app menu) is unreachable from a language pack

[nemezida1337]

Context: I maintain a language pack for DSH — an external client plugin that adds Russian to the web UI (3058 interface strings and 421 plugin display strings, https://github.com/nemezida1337/dsh-locale-russian). It works on 0.1.5-rc.x and 0.2.1-rc.2 and passes its checks on Linux and Windows, but it runs into two things an external plugin cannot reach around. Both are below with code references.

Summary. A profile plugin cannot localize the desktop shell: the welcome
window, the application menu, and the "Manage dsh Command" dialog keep their own
closed en/zh dictionary inside app.asar.

What happens today. apps/desktop/src/locale.ts opens with
/** Typed English and Chinese copy owned by the Electron shell. */ and holds
every shell string (cliCommandMenu, aboutMenu, fileMenu, quitApplication, …).
The welcome window receives its locale through the --dsh-welcome-locale=
switch handled in apps/desktop/src/preload-welcome.ts, and renders copy in
apps/desktop/src/client/WelcomePage.tsx.

Meanwhile the browser side uses the extensible catalog: a client plugin calls
ctx.locale.addLanguage({ id, label, fallback }) and its language appears in
Settings → Language (packages/client/locale/README.md, "Registering a language
pack"). So a Russian user installs a language pack, gets a fully Russian web UI —
and still reads English in the first window the application ever shows, plus the
native menu bar.

Why a plugin cannot fix it. The shell copy is compiled into the Electron
main/preload bundles inside app.asar. Profile plugins run in the host and
browser planes; nothing they can register reaches that dictionary, and editing
app.asar is not a supported path (signature, auto-update).

Proposal. Either

1. Move the shell copy into the same extensible catalog the browser uses (the
   desktop shell already resolves a locale id at window creation, so the
   plumbing exists), so a language pack adds ru for the shell too; or
2. Let the shell read locale/<id>.json exported by the desktop package, as the
   plugin display metadata does (PluginLocalizedMeta reads exported locale
   JSON); or
3. If the shell set stays closed, say so in the locale README, so language packs
   can state the limitation honestly instead of implying full coverage.

Scope that stays out. Nothing here asks for translated model-facing text:
tool descriptions, system prompts, and provider diagnostics should remain
English, and the language pack keeps them verbatim.