fix(web): register configured shell hooks for Web UI sessions

[andyst-dev]

Fixes #83980

Problem

Ordinary hermes dashboard Web UI sessions never registered the lifecycle hooks declared in cli-config.yaml. agent.shell_hooks.register_from_config() had call sites in cli.py and gateway/run.py but none on the Web UI path. So the persistent Relay observability (and any config-defined shell hook) silently stopped emitting for Web UI chats — while the same config looked healthy on CLI, TUI, messaging, and webhook surfaces.

Root cause

The FastAPI app's lifespan never invoked register_from_config. Web UI sessions built the agent but skipped the config-driven hook and outbound-webhook registration that every other surface performs at startup.

Fix

Register declarative shell hooks and outbound webhooks from the loaded config during the FastAPI lifespan (hermes_cli/web_server.py), mirroring the gateway and CLI call sites. The web server has no TTY, so consent is resolved from the same opt-in channels (--accept-hooks, HERMES_ACCEPT_HOOKS, hooks_auto_accept). Failures are logged but never block startup — identical to the gateway path.

Tests

Added tests/hermes_cli/test_web_server_registers_config_hooks.py: starts the app through TestClient (which runs the lifespan) with register_from_config/outbound-webhook registration patched at the source module, and asserts the web server calls them with the loaded config and consent resolved internally (accept_hooks=False).

Verified: new test passes, existing web-server tests (test_web_server_git, test_web_server_config_offloop) still pass, ruff clean.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(web): register configured shell hooks for Web UI sessions

1. hermes_cli/web_server.py (lifespan): the registration failure path logs at DEBUG (_log.debug(..., exc_info=True)). This PR exists precisely because a configured observability hook silently disappeared for Web UI sessions; swallowing registration failures at debug level recreates the same silent-failure class in production. Keep startup non-blocking, but log at WARNING so a misconfigured hook is visible in agent.log.

2. Double-registration risk: the lifespan registers hooks from config, but other surfaces in the same process (gateway runner, per-agent construction in CLI/TUI paths) also call register_from_config. If registration is not idempotent, a Web session could fire hooks twice (or the same hook object registered multiple times). Worth verifying register_from_config dedups by hook identity, and if it does, a one-line comment here stating that would close the question.

3. Test gap: test_lifespan_registers_shell_hooks_from_config asserts the registration calls happen with the right args, but not that a registered hook actually fires during a Web session agent turn (register → invoke chain). The current assertion covers the call site; a light end-to-end check would guard against a future refactor that registers but never invokes.

[andyst-dev]

Addressed the review points on this PR.

Point 1 (log registration failure at WARNING, not DEBUG): done. A configured hook silently vanishing is exactly the failure this PR exists to fix (Web UI sessions previously skipped configured hooks entirely), so the lifespan failure path now logs at WARNING (with exc_info=True) instead of DEBUG — a misconfigured hook is visible in agent.log while startup still never blocks.

Point 2 (double-registration): verified — agent/shell_hooks.register_from_config dedups by hook identity under a lock: each (event, command, matcher) key is checked against _registered before registering (and again before appending), so repeated registration from multiple surfaces (gateway, CLI/TUI, and this Web lifespan in the same process) cannot fire a hook twice. The docstring already notes "already registered" entries are logged but not returned.

Point 3 (register → invoke chain): the existing test_lifespan_registers_shell_hooks_from_config asserts the lifespan calls register_from_config and outbound_webhooks.register_from_config with the loaded config and accept_hooks=False; a full register→invoke E2E over an agent turn is heavier scope than this call-site regression, but the dedup check above plus the call-site assertion cover the wiring this PR adds.

Validation: pytest tests/hermes_cli/test_web_server_registers_config_hooks.py → 1 passed.

[andyst-dev]

Rebased on current main (web_server refactored; shell-hooks registration re-injected after thread start, accept_hooks=False, failures log WARNING not blocking boot). test_web_server.py → 185 passed (2 pre-existing env failures — web dist/theme build — also fail on clean main). Mergeable.