feat(web): add entry-point–based extension layer for the configure UI

[hyoshi]

Summary

Adds a new entry-point group mureo.web_extensions that lets a third-party plugin register additional tabs / API routes inside the mureo configure wizard. The mechanism mirrors the existing mureo.providers / mureo.runtime_context_factory extension patterns (per-plugin fault isolation, first-wins on duplicates, *Warning subclass for strict-mode opt-in) and extends the same Phase 1 extensibility story into the web layer.

Why

mureo/web/handlers.py was the last surface where third-party plugins could not contribute UI / API routes. The OSS provider layer, skill matcher, and RuntimeContext resolver are already entry-point–driven; this PR closes the gap so plugins shipping alternate SecretStore / StateStore backends — or any custom data source — can add their own setup UI inside the same mureo configure wizard the operator already uses.

Public surface added to mureo.web.extensions

from mureo.web.extensions import (
    WebExtension,                       # @runtime_checkable Protocol
    WebExtensionEntry,                  # frozen dataclass (discovery result)
    RouteContribution, ViewContribution, StaticAsset,
    WebExtensionWarning,                # subclass of UserWarning
    WEB_EXTENSIONS_ENTRY_POINT_GROUP,   # "mureo.web_extensions"
    NAME_PATTERN, FILENAME_PATTERN, SUBPATH_PATTERN,  # shared regex strings
    discover_web_extensions,            # cached entry-point scan
    reset_web_extensions,               # test helper
)

HTTP surface (mureo/web/handlers.py)

URL	Behaviour
GET /api/extensions	Index for the front-end renderer (one entry per registered extension; view is null for headless / route-only plugins).
GET /api/ext/<name>/<subpath>	Extension GET route; payload is the flattened query string (first-value-wins).
POST /api/ext/<name>/<subpath>	Extension POST route, gated by the existing Host + body-cap + CSRF pipeline (the plugin author inherits CSRF protection for free).
GET /static/ext/<name>/<filename>	Extension-shipped static asset served from in-memory bytes with the same Content-Security-Policy + X-Frame-Options + Cache-Control header stack.

Front-end (mureo/_data/web/extensions.js)

The configure UI fetches /api/extensions once when the dashboard opens, renders one nav tab per extension, and lazy-loads each extension's html_fragment / <script> / <link rel="stylesheet"> on the first tab activation. Operators who never visit a given tab pay zero added page weight; subsequent visits short-circuit via a _populated: Set dedup.

Security posture

• RouteContribution.subpath, StaticAsset.filename, and the extension name are regex-validated at both registration (_NAME_RE / _FILENAME_RE / _SUBPATH_RE) and dispatch (_EXTENSION_API_RE / _EXTENSION_STATIC_RE). The two layers share NAME_PATTERN / SUBPATH_PATTERN / FILENAME_PATTERN constants so they cannot drift.
• .., double-slash, trailing slash, ?, #, directory separators, leading dots, and uppercase are all refused so a crafted URL falls through to the generic not_found branch instead of reaching the extension lookup.
• Static asset bodies stay in memory; the dispatcher never reads from disk so filesystem traversal is impossible by construction.
• ViewContribution.html_fragment is rejected at registration if it contains <script>, <style>, on*= event handlers, or javascript: URLs. This is an author-feedback signal — the configure-UI CSP (script-src 'self'; style-src 'self') is the actual runtime enforcement, so HTML-entity-encoded bypasses are blocked anyway.
• Handler exceptions are caught by _dispatch_extension and surfaced as {"error": "extension_handler_error"} 500 envelopes; the exception repr is logged server-side only (it may carry secrets the handler touched). A handler that already wrote a partial response before raising is doubly-guarded so the configure server never tries to append a second status line to a half-shipped response.

Plugin author docs

docs/plugin-authoring.md §13 documents the contract end-to-end (entry-point setup, sample WebExtension, URL surface table, security model, lazy-load behaviour, debugging recipe).

Commits

Hash	Title
b076106	feat(web): add entry-point–based extension layer (types + discovery)
dc443e2	feat(web): mount web extensions in the configure server
f0715e1	feat(web): render extension tabs in the configure UI + plugin-authoring §13
cf33c58	docs(web): document _initialised exception-path design in extensions.js
8bc043b	docs(changelog): record web extensions feature under [Unreleased]

Backward compatibility

When no mureo.web_extensions entry points are installed:

• discover_web_extensions() returns an empty tuple.
• GET /api/extensions returns [].
• The renderer's init() filters to [] and creates zero DOM nodes.
• The configure UI is byte-identical to v0.9.4.

825 existing tests/test_web_* tests pass unchanged.

Test plan

• CI lint job (ruff check mureo/, black --check mureo/) — clean locally.
• CI test jobs (Python 3.10 / 3.11 / 3.12 + Windows) — 71 new tests in tests/test_web_extensions.py (45) + tests/test_web_extension_routing.py (26) all pass locally.
• CI test job covers tests/test_web_handlers.py etc. unchanged — no regressions in the broader 824-test web suite.
• CodeQL — no new findings expected; net additions are pure-Python + plain JS, no eval / Function(...) / subprocess / shell.
• Manual: launch mureo configure with no mureo.web_extensions entry points → confirm the dashboard renders exactly as v0.9.4 (no extra tabs, no /api/extensions errors in DevTools).