Support local custom CSS with live reload for workspace and Electron shell

[riccardomarotti]

Is your feature request related to a problem? Please describe.

Rocket.Chat Desktop can follow the application's built-in theme and the
appearance provided by the connected Rocket.Chat server, but there is no
generic way for a desktop user to apply local styling to the complete Desktop
application.

This is useful especially on Linux desktops, where applications can be
integrated with a desktop-wide theme or an external theme manager.

Server-side Custom CSS can customize the Rocket.Chat web application, but it
solves a different problem:

• it is configured at server level;
• the user may not have permission to change it;
• it controls the shared Rocket.Chat appearance rather than one local client;
• it cannot dynamically follow the local desktop theme;
• it cannot style the Electron shell.

Styling only the Electron shell would also be insufficient for desktop theme
integration, because the workspace webview represents most of the visible
application.

For a Desktop installation to integrate consistently with its local
environment, both renderer surfaces need to support local styling.

Describe the solution you'd like

Add support for two optional local stylesheets in the application's user-data
directory:

custom.css
    -> Rocket.Chat workspace webviews

custom-shell.css
    -> Electron desktop shell

If either file is absent, the corresponding UI should behave exactly as it does
today.

When present, the stylesheets can be applied using Electron's
WebContents.insertCSS() API.

Changes to the files should be detected at runtime and reapplied automatically
without reloading the workspace or Electron renderer.

Deleting a stylesheet should remove the locally injected CSS and restore the
normal application styling.

The two stylesheets should remain independent because the workspace and the
Electron shell are separate renderer contexts with different DOM structures.

This feature should be completely local and generic. It should not depend on
any particular Linux desktop, theme system, or external application.

Relationship with server-side Custom CSS

This is not intended as a replacement for Rocket.Chat server-side Custom CSS.

Server-side Custom CSS controls the shared appearance of the Rocket.Chat web
application.

Local Desktop CSS would instead control how a particular Rocket.Chat Desktop
installation integrates with its local environment.

This distinction is particularly important for desktop theme managers, which
need to update both the Electron shell and the workspace shown inside it.

Describe alternatives you've considered

Server-side Custom CSS

This works for server-managed customization of the Rocket.Chat web UI, but does
not solve local desktop integration because it cannot style the Electron shell
or independently follow each user's desktop theme.

Styling only the Electron shell

This leaves most of the visible application — the Rocket.Chat workspace —
unchanged, so it does not provide consistent desktop theme integration.

Maintaining a patched Desktop fork

This works technically, but requires maintaining a separate Desktop build for
functionality that can be implemented generically in the upstream client.

Reloading the renderer when the theme changes

This would unnecessarily disrupt the application state. Electron supports
replacing inserted stylesheets without reloading the renderer.

Additional context

A working proof of concept has already been tested using Electron's
insertCSS() / removeInsertedCSS() APIs.

The prototype supports:

• loading the stylesheets at startup;
• live updates while Rocket.Chat Desktop is running;
• independent workspace and Electron-shell stylesheets;
• stylesheet creation and deletion;
• atomic file replacement;
• debouncing repeated filesystem events;
• workspace webview reloads;
• Electron shell renderer reloads;
• preservation of the current conversation, draft text and scroll state;
• no page or application reload when the stylesheet changes.

The implementation can remain generic and independent of any particular theme
manager.

Before preparing a pull request, I wanted to check whether this is functionality
the project would be interested in supporting upstream and whether maintainers
have preferences regarding the local file names or integration point.