feat(dashboard): Let users hide modules/apps from their dashboard and navigation

[pchopinet]

Summary

Let each user hide modules/apps they do not use from their own navigation and dashboard. This is a personal preference (self-service), not an administrative restriction.

Motivation

Not everyone uses every module. A user who never touches Mail or Calendar should be able to declutter their sidebar, command palette, and dashboard by hiding those modules, without an admin having to do anything.

User story

As a user, I want to hide modules I do not use from my navigation and dashboard, so my workspace only shows what is relevant to me, and I can re-show them later.

Scope

• A per-user preference storing the set of hidden module slugs.
• Hidden modules are removed from: the nav/sidebar, the command palette, and the dashboard widgets/launcher.
• A settings UI (e.g. under user preferences) to toggle each module's visibility on/off.
• Reversible at any time; defaults to all modules shown.

Non-goals / important distinction

• This is cosmetic personalization, not access control. A hidden module stays fully accessible by direct URL; we are only hiding it from this user's chrome.
• This is distinct from the admin-driven per-group/global module restriction explored in PR wip: feat(core): restrict module access globally or per group #277 (feat/module-access-control), which enforces 403s and is configured by an administrator. The two can coexist: admin restriction decides what a user may access; this feature lets a user hide what they choose not to see among what they can access.

Implementation notes

• The module list already comes from the central ModuleRegistry (workspace/core/module_registry.py), surfaced to templates via the workspace_modules context processor. Filtering the user's hidden slugs there (similar to how disabled modules are already filtered) is the natural hook.
• Store the preference through the existing user-settings service (workspace.users.services.settings), e.g. module="core", key="hidden_modules", value=["mail", "calendar"] (cached + invalidated on write, per the settings convention). Do not hit UserSetting.objects directly.
• The toggle UI can follow the existing fire-and-forget settings pattern (PUT /api/v1/settings/<module>/<key>), like the dashboard preferences form.
• Core/infrastructure entries that must always be reachable (dashboard itself, user settings) should not be hideable.

Acceptance criteria

• A user can hide and unhide each module from a settings screen.
• Hidden modules disappear from that user's nav, command palette, and dashboard, and reappear when unhidden.
• The preference persists across sessions and is per-user only.
• Hidden modules remain reachable by direct URL (no access change).