Guard spawn agent activity labels

[itkonen]

Sometimes Codex provides sub-agent activity labels that are extremely long, nonsensical, or repeat the same text over and over. This bloats the dialogue and can also pollute the tool-call history that later model turns may see. This PR adds a small guardrail to prevent that issue.

---

The summary below was generated by AI.

• I added a entry in changelog under unreleased section.
• This is not an AI slop.

Summary

• Normalize spawn_agent activity arguments by trimming, collapsing whitespace, truncating overly long labels, and omitting blank or non-string labels.
• Apply normalization before pre-tool-call hooks and again after hook-modified arguments so stored/replayed tool-call arguments stay clean.
• Format subagent summaries without a trailing activity suffix when the activity is omitted.

Verification

• clojure -M:test --focus eca.features.tools.agent-test
• clj-kondo --lint src/eca/features/tools/agent.clj src/eca/features/chat/tool_calls.clj test/eca/features/tools/agent_test.clj

[ericdallo]

@itkonen Can you give me a example from eca stderr or something to understand better how codex behave?

[itkonen]

@ericdallo There's actually nothing in the stderr.

The main issue is with the user-facing labels printed out in the chat. Sometimes the label is just gibberish or exotic unicode symbols, but sometimes it's really, really long. Like here in this subagent call the label was over 13000 characters, filling multiple pages on my screen:

reviewer: reviewing label guardrail fixes upstream quality and downstream model context contamination risks with very long label handling and schema side effects repeated repeated repeated repeated repeated ... [about 13000 characters in this label!] ... repeated repeated repeated (6 steps) ✅ 4m 30s

A secondary issue is that this long label might get passed forward in later chat turns, filling up the LLM context window.

My guess is that Codex uses a small specialized model to generate the tool calls that ECA receives, and that model knows only how to write the tool call payload but easily fails at writing sensible action labels. And that model might get stuck in a loop repeating a word or a phrase over and over again.

So in this PR implements minimal guardrails to limit the length of the label and prevents it from bloating further model requests. The user will still see the gibberish but at least it will not harm the workflow.