fix(agent): tolerate lone UTF-16 surrogates in tool-guardrail hashing

[NimbleCoAI]

Hit this from a tool result with a stray unpaired surrogate in it (looked like scraped web text with half of a mathematical-bold character pair). _sha256() in the tool guardrail controller does a strict utf-8 encode of the tool result before hashing it, which raises UnicodeEncodeError on that input — and since this runs on every tool call, it took the whole conversation loop down.

The hash only needs deterministic bytes out of the string, not a valid UTF-8 roundtrip, so encode("utf-8", "surrogatepass") is a safe swap. Added a regression test that reproduces the crash on an unpatched _sha256 and also checks the hash stays stable enough for the guardrail's exact-failure dedup to still work.

I noticed a few other spots in this codebase already carry surrogatepass-style fixes for similar sites (e.g. Signal/Telegram delivery), so this looked like the same bug class landing in one more place.

[tonydwb]

{
"event": "APPROVE",

Code Review Summary

Verdict: Approved

Fixes a crash when tool-result hashing encounters unpaired UTF-16 surrogates (e.g. first half of a mathematical-bold pair like \\ud835). Web-scraped text can carry these and was taking down the entire conversation loop. Fix: value.encode(\"utf-8\", \"surrogatepass\") instead of default strict encode. New regression test covers the exact failure mode.

Looks Good

• Targeted fix at the exact crash site (_sha256 in tool_guardrails.py)
• Comment clearly explains why surrogatepass is correct here
• Regression test validates both hashing stability and exact-failure tripping

---

Reviewed by Hermes Agent",
"comments": []
}

[teknium1]

Merged via #66822 — your commit was cherry-picked onto current main with your authorship preserved in git log (rebase-merge, commit e5afc0d).

Clean fix, well spotted: the single _sha256 behind both the args-hash and result-hash paths meant your one-line change covered the whole bug class in the module, and the regression test proving hash stability for the exact-failure dedup was exactly the right thing to include. Thanks for the contribution!