feat(shells): switch shells from the user menu, and unregister the legacy Dashboard

[delchev]

Three related fixes to how the shells are reached.

1. A shell switcher under the user icon

Every Harmonia shell's user menu now carries Home plus every other registered shell, so switching no longer means a detour through the launchpad:

  admin
  ─────────────
  Switch to
   ⌂  Home
   ▦  Applications
   ✦  Builder
   ✉  Personal
   🤝 Partner
   🛡  Administration
   <> Workbench
  ─────────────
   ⏻  Log out

The list comes from the same platform-shells aggregation Home renders, read by a new shared application-core/shell/js/stores/shells.js — so a stack that contributes a shell gets it in the switcher for free, with no second registration, and each shell leaves itself out of its own list (isCurrent against App.config.basePath). Icons come from each shell's own registration, with a fallback map. Reachability stays the platform's business: a shell your roles don't allow answers 403 when opened, exactly as it does from Home — the listing has never been role-filtered and this doesn't invent that.

The markup is a dozen lines per shell (each shell owns its own chrome); the logic lives in application-core, once. The six shells: Applications, Personal, Partner, Administration, Monitoring, Builder.

2. The legacy Dashboard shell is no longer registered

It was superseded by the Harmonia shells and Home already hid it — but the IDE's Window ▸ Shells menu listed it anyway, offering the old AngularJS/BlimpKit dashboard as a peer of the shells that replaced it. Removing its platform-shells extension drops it from both surfaces at once. The module itself stays: the generated views still load dashboard/services/*. With nothing left to hide, Home's HIDDEN list becomes empty.

Its two perspectives (application-perspectives: Dashboard, Reports) are untouched — say the word if those should go too.

3. Why none of this was showing up: a 30-day cache on the menus

menus.js and shells.js answered public, must-revalidate, max-age=2592000 with a random-UUID ETag. So the browser served a month-old menu without asking the server, and the ETag could never match even when it did ask. That is why the "My Work" → "Personal" rename never appeared in an open IDE's Window menu, and why a newly published shell looked missing.

Both now answer private, no-cache (matching the projections service): this is content, re-aggregated whenever an artefact is published, not a static asset. Verified on a running instance:

$ curl -sD- .../extension-services/shells.js | grep -i cache-control
Cache-Control: private, no-cache

$ ... /extension-services/menus.js  → Window ▸ Shells:
['Applications', 'Builder', 'Personal', 'Partner', 'Administration', 'Monitoring', 'Workbench']

Correct labels, no Dashboard. The same defect exists on perspectives.js / views.js / editors.js / themes.js / templates.js / locales.js — left alone here since the Window menu aggregates its content server-side, but worth a follow-up.

Verification

• mvn -T 1C clean install -P quick-build — green.
• New ShellSwitcherIT (2 tests) — opens the menu in two different shells and asserts each lists the others plus Home, and omits itself. MonitoringShellIT (2) still green.
• Checked in a real browser: the menu renders as above, with the current shell (Monitoring) correctly absent.

🤖 Generated with Claude Code