hermes - 💡(How to fix) Fix Stale dashboard plugin cache persists after plugin directory is removed from disk

Description

When a bundled dashboard plugin is removed from the filesystem (e.g., after git pull removes it from the repo), the in-process Python cache _dashboard_plugins_cache in web_server.py still holds the stale plugin metadata. The frontend still sees it in the /api/dashboard/plugins response and tries to load its JS bundle from /dashboard-plugins/{name}/dist/index.js, but the file no longer exists → 404 on the script load.

Reproduction

1. Have a bundled dashboard plugin with manifest.json on disk (e.g., the example plugin that was recently removed from the repo)
2. Remove its directory: rm -rf plugins/example/
3. Do not restart the dashboard (the cache lives in Python process memory)
4. Open the tab in the browser → browser console shows "Failed to load resource: 404" for /dashboard-plugins/example/dist/index.js
5. The plugin listing API still returns the stale entry

Location

hermes_cli/web_server.py:

• Line 4000: _dashboard_plugins_cache: Optional[list] = None — a module-level cache that is populated on first request and never invalidated
• Line 4003-4007: _get_dashboard_plugins() — only rescans when force_rescan=True
• Line 4294-4329: serve_plugin_asset() — trusts plugin["_dir"] from the cache without verifying the directory still exists

The manual recovery endpoint exists (/api/dashboard/plugins/rescan) but there is no automatic invalidation.

Suggested fix

Options (from simplest to most thorough):

1. In serve_plugin_asset(), if the resolved file path does not exist, trigger an automatic rescan and retry once before returning 404.
2. Validate plugin directories exist before inserting into cache (or at least at read time).
3. Invalidate the cache by comparing plugins_root directory mtime on each API call (cheap os.stat).

Option 1 is minimal and directly addresses the user-visible symptom. Option 3 is the most robust.

Environment

• Hermes commit: ced1990c1cab
• Platform: Linux
• Dashboard process uptime: 2+ days (no restart between plugin removal and the error)