fix: avoid re-injecting todo subjects after compression

[batchprocess128]

Summary

Fixes a todo privacy boundary in Hermes' post-compression state recovery.

Before this change, TodoStore.format_for_injection() appended full pending and in-progress todo subjects back into the compressed conversation as a user message. Todo subjects are useful for local planning, but they can contain sensitive task details. Re-injecting them into fresh model context after compression can re-surface details that should stay local to the original tool result.

This PR keeps todo continuity without re-surfacing full subjects after compression:

• post-compression injection now includes active todo counts only
• the model can call todo with no parameters when it needs full details
• the todo tool schema now warns that todo content can be visible in UI and tool results
• tests now assert that active todo subjects are not re-injected

Test plan

python -m pytest tests/tools/test_todo_tool.py tests/tools/test_read_loop_detection.py -q -o 'addopts='

Result:

37 passed

Risk / compatibility

This changes only the post-compression injection text. Normal todo reads/writes still return the full current list, and the live UI can still render todos from tool events.

The tradeoff is intentional: after compression, the model gets continuity counts and must explicitly call todo to inspect full task details rather than receiving all active subjects automatically.

[teknium1]

Thanks for the focused privacy hardening. The underlying behavior is still present on current main: tools/todo_tool.py:138-143 includes active subjects in the formatted snapshot, and agent/conversation_compression.py:703-705 appends that snapshot as a synthetic user message.

Problems

• The proposed counts-only text removes subjects, but retains the synthetic-user-message mechanism. Linked issue Avoid injecting raw todo snapshots as synthetic user messages after compression #26979 explicitly tracks avoiding tool-derived content as a fresh user instruction; the linked alternatives Prevent todo snapshot injection after compression #26981 and fix(agent): preserve todos as tool state after compression #58162 use different representations. A maintainer needs to select the canonical boundary before this narrow approach is salvaged.

Suggested changes

• If counts-only injection is chosen, add a compression-path regression test asserting an instruction-like todo subject is absent from the returned compressed messages, while the active counts remain present. If the Avoid injecting raw todo snapshots as synthetic user messages after compression #26979 role-boundary guarantee is chosen instead, preserve todo state outside a synthetic user turn.

Automated hermes-sweeper review.