fix(dashboard): refresh plugin manifests automatically

[camaragon]

Why

Dashboard extension manifests are cached for the lifetime of the web-server process. Installing, editing, or removing a frontend-only dashboard extension after the cache is populated leaves GET /api/dashboard/plugins stale until an explicit rescan or process restart.

What changed

• Factor dashboard plugin search-root discovery into a shared helper.
• Fingerprint manifest path, mtime, ctime, and size before serving the cached manifest list.
• Re-discover frontend extension manifests when one is added, edited, or removed.
• Document automatic frontend refresh and the backend API-route restart boundary.
• Add current-main regression coverage for manifest add/update/removal.

Scope

This refreshes dashboard manifests only. Static plugin assets retain stable URLs and the existing Cache-Control: no-store, no-cache, must-revalidate response. Backend plugin API routers retain their process-start mount lifecycle; this PR does not hot-load or unload Python routes or model tools.

No user-specific plugin content is included.

Verification

• focused dashboard/plugin tests — 24 passed
• Ruff on changed Python files — passed
• Python compile checks — passed
• git diff --check — passed

Risk

Low. The backend adds a small directory/stat fingerprint before returning the cached dashboard manifest list. Existing manifest validation, source precedence, enable/disable filtering, static-asset allowlisting, and API-route trust gates are unchanged.

Related issue

Related to #71595. Frontend dashboard manifests refresh automatically; process-global Python plugin/tool enablement remains restart-bound.

[teknium1]

Thanks for addressing a real dashboard refresh gap. Current main returns the cached manifest list unless the cache is empty, explicitly rescanned, or a cached plugin directory disappears (hermes_cli/web_server.py:16407-16414), so additions and manifest edits remain stale.

Problems

• The asset-versioning rationale does not hold for the current server response: plugin assets already return Cache-Control: no-store, no-cache, must-revalidate (hermes_cli/web_server.py:16795-16799). A conforming browser does not reuse the stable-URL response.
• The documented lifecycle still says discovery is cached and directs users to rescan or restart (website/docs/user-guide/features/extending-the-dashboard.md:816-823), which would become inaccurate.

Suggested changes

• Keep the manifest fingerprinting fix, but remove the redundant asset-versioning path unless a concrete cache layer that bypasses the existing no-store response is identified.
• Update the dashboard-extension documentation; preserve the backend API-route restart caveat at website/docs/user-guide/features/extending-the-dashboard.md:914-917.

Automated hermes-sweeper review.

[camaragon]

Refreshed onto current main and addressed review in c5c3ac2029.

Changes:

• kept automatic manifest fingerprinting for add/edit/remove detection
• removed redundant frontend asset-version URL changes and tests
• documented automatic frontend manifest refresh while preserving the backend API-route restart boundary
• recreated focused current-main regression coverage

Verification:

• focused dashboard/plugin tests: 24 passed
• Ruff: passed
• Python compile checks: passed
• git diff --check: passed

[camaragon]

Refreshed onto current main at 3ca770e47a and resolved the web_server.py replay conflict by preserving current os.scandir discovery plus the PR manifest fingerprint invalidation. Fresh local verification: focused dashboard/plugin suite 188 passed, 1 skipped; Ruff passed; git diff --check passed. The prior asset-versioning review request remains addressed and no unresolved review threads remain. Fresh GitHub CI is running on the new head.