perf(tui): fix CPU lockup and O(N) scans during waiting/running states

[mattimustang]

Summary

Fixes 100% CPU utilisation that occurred during the waiting state between agent runs, caused by redundant 60fps re-renders and O(N) scans over all tool executions on every frame.

• Fix O(N) scans across all tool executions by indexing lookups through agent_data["tool_executions"] instead of scanning the full tracer.tool_executions dict
• Eliminate redundant 60fps renders during waiting state by skipping agent status display updates when the dot animation timer is inactive
• Cache completed event renders to avoid re-rendering unchanged content on every refresh during running state

Details

During the waiting state the TUI was re-rendering all events at 60fps even though nothing changed, and several helper methods (_agent_has_real_activity, _agent_vulnerability_count, _get_agent_name_for_vulnerability, _gather_agent_events) each did a full O(N) scan over tracer.tool_executions to find events belonging to a given agent. Combined, this drove CPU to 100% while the app appeared idle. These methods now use the per-agent tool_executions index for O(1) lookup, and status display updates are skipped entirely when no animation is running.

Test plan

• Run a scan with multiple agents and verify CPU usage drops to near-zero during the waiting state
• Confirm agent events display correctly in the chat view during and after a run
• Confirm vulnerability counts display correctly

[greptile-apps]

Greptile Summary

This PR fixes excessive CPU usage in the TUI during idle/waiting states by replacing four O(N) linear scans over tracer.tool_executions with O(1) per-agent indexed lookups, and adding a completed-event render cache to avoid re-rendering unchanged tool/chat content on every tick.

• _agent_has_real_activity, _agent_vulnerability_count, _get_agent_name_for_vulnerability, and _gather_agent_events now iterate only the per-agent tool_executions list instead of the entire global dict.
• _update_agent_status_display() is skipped in the 0.35 s refresh tick when the dot animation timer is inactive, and the sweep-frame counter advances only for "running" (not "waiting") agents.
• A new _event_render_cache stores completed/failed/error tool renders and finalized chat renders, keyed by event_id (and event_id + status for tools), cleared on agent switch.

Confidence Score: 4/5

Safe to merge; the core logic changes are correct and well-scoped.

The tool-execution indexing is correct and consistent across all four refactored methods, and the render-cache invalidation on agent switch is properly wired. A single leftover O(N) scan over chat_messages in _gather_agent_events means the fix is incomplete for long scans with heavy chat traffic, but it does not introduce any regression.

strix/interface/tui.py — specifically _gather_agent_events where the chat_messages linear scan was not optimized alongside tool_executions.

Important Files Changed

Filename	Overview
strix/interface/tui.py	Four helper methods converted from O(N) global scans to O(1) indexed lookups via agent_data["tool_executions"]; event render cache added for completed tool/chat events; _update_agent_status_display() call gated behind animation-timer check. One residual O(N) scan over chat_messages remains in _gather_agent_events.
strix/skills/vulnerabilities/http_request_smuggling.md	New skill knowledge file documenting HTTP request smuggling detection/exploitation techniques; no code changes, documentation only.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
strix/interface/tui.py:1472-1482
**O(N) chat_messages scan left unoptimized**

`_gather_agent_events` now uses O(1) indexed lookups for tool executions, but `chat_messages` is still filtered with a linear scan (`for msg in self.tracer.chat_messages if msg.get("agent_id") == agent_id`). This function is called on every refresh tick, so a long-running scan with many messages across multiple agents will still exhibit the same per-frame O(N) scan cost, just for a different collection. Consider adding a per-agent index to `chat_messages` in the tracer (similar to `tool_executions`) to make this O(1) as well.

_{Reviews (1): Last reviewed commit: "perf(tui): cache event renders and elimi..." | Re-trigger Greptile}

[mattimustang]

Fixed in d0cbaec.

Added chat_messages_by_agent: dict[str, list[dict[str, Any]]] to Tracer and populate it at write time (setdefault(agent_id, []).append(message_data)). _gather_agent_events now does an O(1) dict lookup instead of a full scan.