fix: register shell hooks in TUI gateway

[orcool]

Summary

Register declarative shell hooks inside the TUI gateway subprocess.

The outer hermes --tui launcher and the actual TUI gateway are separate Python processes. Agent turns in the TUI are handled by python -m tui_gateway.entry, so conversation hooks such as post_llm_call need to be registered in that process as well.

Before this change, hermes hooks test post_llm_call could succeed while real TUI responses did not fire the same hook, because the test command registered hooks in its own process but the TUI gateway hook manager remained empty.

Why

This fixes a TUI-specific process-boundary bug:

• CLI / hook-test paths can register and invoke shell hooks successfully.
• TUI response generation runs in tui_gateway.entry.
• Without registering hooks in that subprocess, post_llm_call and similar lifecycle hooks do not fire after real TUI responses.

One visible symptom is that the existing cmux integration hook:

cmux hooks hermes-agent agent-response

can work under hermes hooks test post_llm_call but fail to run after an actual TUI assistant response.

Changes

• Add _prepare_tui_gateway_hooks() to tui_gateway/entry.py.
• Call it during TUI gateway startup before emitting gateway.ready.
• Keep failures best-effort/non-fatal, matching existing gateway startup behavior.
• Add regression tests covering TUI gateway shell hook registration and startup ordering.

Test Plan

• ./venv/bin/python -m py_compile tui_gateway/entry.py
• ./venv/bin/python -m pytest tests/test_tui_gateway_entry_hooks.py tests/agent/test_shell_hooks.py tests/agent/test_shell_hooks_consent.py -q -o 'addopts='
• Manually verified with the existing cmux integration hook that post_llm_call now fires after real TUI assistant responses once the TUI is restarted.

[alt-glitch]

Competing with #13854 (earliest), #24237 (superset with plugin discovery), and #28953 (adds pre_tool_call content transformation) — all fix the same TUI gateway missing hook registration.

[orcool]

Thanks for pointing these out. Agreed — this addresses the same TUI gateway registration gap.

The main difference in this PR is that it keeps the fix narrow while registering both Python plugins and declarative shell hooks in the actual tui_gateway.entry process, and includes a regression test for that process-boundary behavior.

Two related notes from local validation:

1. This fix only addresses runtime registration in the active TUI gateway process. It does not change Hermes profile scoping. A TUI launched with -p mobile-apps still needs hooks installed/allowlisted under that profile’s HERMES_HOME, e.g.:

HERMES_HOME="$HOME/.hermes/profiles/mobile-apps" cmux hooks hermes-agent install --yes

2. Once TUI hook registration works, cmux-installed pre_tool_call / post_tool_call feed hooks may also start firing in the TUI path. In our local setup those generic tool-feed hooks had 120s timeouts and repeated pre_tool_call timeouts caused noticeable latency. We mitigated locally by disabling pre_tool_call / post_tool_call and keeping prompt/response + approval lifecycle hooks only. That seems separate from this PR, but worth keeping in mind when validating/defaulting cmux hook config.

Happy to close this in favor of whichever existing PR maintainers prefer, or adjust this PR if a narrower/superset direction is preferred.