bug(runtime): safe-boundary resume rejects Runtime-generated tool_search #5872

What happened

Safe-boundary resume can park a stopped run after Runtime successfully generated and executed tool_search. The model-facing history contains the completed tool_search call, but the Host's continuation safety catalog is derived from the base run composer and omits the Runtime-generated connector. The planner then reports tool_catalog_mismatch, which the TUI projects as safety_check_failed.

I reproduced this against a persisted run with completed tool_search and WebFetch results. The saved base composition contains WebFetch but not tool_search; replay planning parks for the missing tool_search. Adding the effective Runtime connector name makes the same isolated plan ready. This is not a T1-without-T2 / unknown-tool-outcome case.

How to reproduce

1. Start a TUI turn with deferred tool groups, so Runtime injects tool_search.
2. Let the model call tool_search and another tool, with both results committed.
3. Stop the turn and request safe-boundary resume.
4. When other safety checks pass, the planner still parks because tool_search is absent from the Host's available-tool catalog.

Expected: resume validation uses the effective Runtime tool catalog, including Runtime-generated connectors present in the continuation surface, and accepts the replay when the other safety checks pass.

Environment

• Maka commit used for reproduction: 064997019b (the relevant code is unchanged on current main ed38ccbb6b)
• OS: Linux x86_64
• Surface: TUI / Runtime Host
• Node.js: v26.3.0

Logs, screenshots, or additional context

The reproduction used the persisted event sequence and base tool composition without publishing session IDs or user content. The planner's concrete rejection is tool_catalog_mismatch with unavailableToolNames: ["tool_search"].