feat(chat): load WebUI prefill context

[AJV20]

Summary

• Load configured WebUI prefill context from prefill_messages_file or prefill_messages_script for browser-originated chat turns.
• Pass the loaded recall as ephemeral prefill_messages to Hermes Agent without persisting message bodies into the WebUI transcript.
• Emit a compact context_status SSE event so the browser can show whether recall loaded or failed without exposing prefill content.

Test plan

• /Users/abdiel/.hermes/hermes-agent/venv/bin/python -m pytest tests/test_webui_prefill_context.py -q -o 'addopts='
• /Users/abdiel/.hermes/hermes-agent/venv/bin/python -m py_compile api/streaming.py
• node -c static/messages.js
• git diff --check

[nesquena-hermes]

Phase 0 fit assessment — needs maintainer direction before further review

Thanks for the WebUI/Agent prefill parity slice, @AJV20. The implementation is careful (token redaction in _redact_prefill_status_text, capture_output/timeout=20/no shell on subprocess, no message bodies sent over SSE, defensive prefill_messages kwarg pop for older agent builds). But before further review I want to flag this for a fit-decision per Phase 0, because the surface-shape question matters more than the per-line correctness:

Q2 (right shape) concerns

1. New subprocess-execution-from-config surface. _load_webui_prefill_context reads prefill_messages_script from config.yaml (or HERMES_PREFILL_MESSAGES_SCRIPT env) and subprocess.run([...], cwd=path.parent) on every chat turn. This is a real new attack surface — anyone with write access to config.yaml (or the env) gets code execution on every turn. WebUI already has a tools_disabled/MCP layer for "run a thing when the agent asks"; adding a second always-on, untyped, per-turn shell-out path needs explicit maintainer buy-in.

2. Cross-repo contract dependency. The PR passes prefill_messages as a new kwarg to agent.send_turn() (or the equivalent in AIAgent). That's a Hermes Agent contract change — the defensive _agent_params introspection guard catches the absence gracefully, but if we ship this without a paired hermes-agent change, the feature is silently dead-code on master.

3. Surface naming: "prefill" is overloaded — the existing prefill_messages_* config keys in hermes-agent are for the headless gateway path. Calling the new WebUI feature "prefill parity" tries to share the same keys but doesn't share the same loader semantics (you added a script-output-as-one-user-message shape that hermes-agent's loader doesn't have). Either we adopt this shape in hermes-agent too, or the WebUI feature wants its own key like webui_session_recall_script.

Alternatives to consider

1. MCP path: route session recall through an MCP server (the standard "do a thing on demand" surface) instead of a per-turn subprocess. The agent already wires MCP tools; the user just configures a Joplin-or-equivalent MCP server.
2. File-only path: keep prefill_messages_file but drop prefill_messages_script. The file path is bounded (read once, no execution), the script path is the open-ended one.
3. Reject: rely on memory/notes/MCP for cross-turn recall — they exist for this purpose and avoid the new per-turn subprocess.

Applying maintainer-review for @nesquena to weigh in on direction. Happy to take the file-only slice ourselves as a small follow-up if that's the chosen path, or to wait and absorb a revised version. The diagnosis (browser sessions feel context-thin vs headless) is real; the implementation shape is what I want to step back on.

[AJV20]

Superseded by #2547, which carries the WebUI prefill-context work forward in a consolidated context-parity PR.