Runtime does not start workers for tools declared on a `planner=` agent

Start in src/conductor/ai/agents/runtime/runtime.py, focusing on how worker tools are collected for an agent and its planner= and fallback= slots. Reproduce with examples/agents/86_coding_agent.py and verify that it reaches the planner instead of hanging; the later "No JSON plan found" failure is a separate defect.

In short: an agent passed as planner= gets no workers started for its tools, so its tasks sit in the queue with nothing polling them and the example hangs forever.

Files: src/conductor/ai/agents/runtime/runtime.py; reproduced by examples/agents/86_coding_agent.py

Symptom

$ python examples/agents/86_coding_agent.py

Hangs forever, no output after the worker banner. Output at 180s and 300s is byte-identical — no progress. Still reproduces on Orkes Conductor 5.5.0 against main at 8ff5f88f (240s, no progress).

Cause

Workers start only for the parent agent's tools=. Tools declared on the agent passed as planner= get none, so the planner's read_file tasks stay SCHEDULED with nothing polling them.

• grep -n '\.planner' runtime.py matches only comments — no code reads that slot when collecting worker tools.
• _ensure_models_for_agent walks a.agents recursively, so the old form was covered.
• The named slots planner= / fallback= replaced the older agents=[planner, fallback] form, and the traversal was never extended to them.

Fix

Collect worker tools through planner= and fallback=, not only agents=.

Verify

python examples/agents/86_coding_agent.py reaches the planner and stops hanging. Confirmed: supplying those four workers from a second process ends the hang (128s vs indefinite).

Notes

This does not make 86 pass. It then fails with No JSON plan found and no fallback agent configured, a separate defect.

Reproduce on Orkes Conductor 5.5.0, not OSS 3.32.0. On OSS 3.32.0 the example no longer reaches this hang — it fails first, at 42s, with a separate defect that masks this one:

Plan compilation failed: Validation 0 has unsafe success_condition:
unexpected trailing input: '('passed') >= 0' at position 9 in: $.indexOf('passed') >= 0

No other example is known to expose this. 115_plan_execute_planner_context.py and adk/24_planner.py both use planner= but cannot reach it, and both pass:

• 115's planner declares the same four tools as its parent harness, so the parent's tools= already starts those workers.
• adk/24_planner.py passes BuiltInPlanner(...), which carries no tools at all.