Explain Hermes's "faces not registered" report: a stale session, not the bridge

A raw MCP client and a fresh `hermes mcp test robot` both list faces, look and
list_people, and Hermes's own log shows it registering all of them at 01:18:46 after
the robot restart and a later session calling faces() fine. The reporting session
started at 00:35, before faces existed, and keeps its start-time snapshot of the tool
table. Record the cause and the fix (start a new Hermes session) in the README
troubleshooting and CONTEXT.md, and note why the bridge keeps stateful sessions.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AFN8nRRCiDiMN7ChBpHJhs

README.md

@@ -171,6 +171,11 @@ about 0.5 px is good. `sudo systemctl restart robot` to load it.
 - **`ros2 node list` shows only some nodes:** use `ros2 node list --no-daemon --spin-time 6`.
 - **The Pi's clock is wrong with Wi-Fi off:** there is no internet to sync from; it stays roughly right
   but unsynchronised.
+- **Hermes says `faces` (or another new tool) is "not a known tool name":** a Hermes session takes a
+  snapshot of its tool table when it starts. If it began before the robot offered the tool (or before a
+  robot restart that added it), it never sees it, even though `robot://status`, `list_prompts` and a fresh
+  `hermes mcp test robot` all show it. Start a new Hermes session. (Hermes's log shows the reconnect
+  and "registered N tool(s)" for the whole process; only that old session keeps its stale table.)
 - **A one-off message to the face is ignored:** ROS drops a message published before the connection
   matches. Republish it, as `hermes_mcp` does every second.