chore(runtime): standardize ThreadStreamEvent send error handling

[jorben]

Summary

Several ThreadStreamEvent send sites intentionally ignore channel send errors with let _ = ...send(...). This matches the current event-flow pattern, but it makes broken or closed frontend event channels hard to observe and diagnose.

This came up during PR review for #153, where a reviewer flagged the new ToolRequested send for task tools as silently ignoring send errors. We chose not to address it in that PR because the same pattern is used broadly across runtime event emission and should be handled consistently rather than patched at one call site.

Current state

• AgentSession and related runtime modules emit many ThreadStreamEvent values through let _ = ...send(...).
• The pattern is used for tool events, run lifecycle events, message streaming events, task board events, and other runtime updates.
• If the channel is closed, execution usually continues and consumers may rely on later snapshot/resync behavior.

Proposed follow-up

Introduce a consistent policy for handling ThreadStreamEvent send failures, for example:

1. Add a small helper for event emission that logs send failures with useful context such as run_id, event kind, and subsystem.
2. Decide which events, if any, should fail fast versus warn-only.
3. Replace ad-hoc let _ = ...send(...) call sites where appropriate.
4. Add tests or tracing coverage for closed-channel behavior if practical.

Acceptance criteria

• There is one documented pattern for emitting ThreadStreamEvent values.
• Send failures are observable at least through structured logs or tracing.
• Runtime behavior remains compatible with existing snapshot/resync recovery paths.
• The change avoids one-off handling for only task tools or only a single event type.

References

• Follow-up from PR: fix(agent): 🐛 Emit requested events for task tools #153
• Review comment: fix(agent): 🐛 Emit requested events for task tools #153 (comment)

🤖 Generated with TiyCode