Support per-agent model selection in workflow scripts

[camerondurham]

Goal

agent(..., { model }) previously added the model name to the prompt but still ran every subagent on the parent model. This PR makes it select the actual Pi model, so workflows can use faster models for fan-out work and stronger models for synthesis. Omitting model still inherits the parent model.

Routing fails early for unavailable or ambiguous models instead of silently choosing another provider. The resolved provider/id is shown in workflow progress and results. Subagents also exclude the workflow tool to prevent recursive workflows, an issue found during live testing with a local model.

Validation

npm test passes all 41 tests.

For the live test, I created a temporary PI_CODING_AGENT_DIR, copied the real Nix-managed auth.json, models.json, and settings.json into it, then installed this checkout with:

PI_CODING_AGENT_DIR="$tmp" pi install /Users/cam/workplace/pi-dynamic-workflows
PI_CODING_AGENT_DIR="$tmp" pi list

On Pi 0.80.6, I ran this workflow through the installed extension:

await parallel([
  () => agent('Reply with exactly LOCAL_GEMMA_CODEX_RETRY_OK and nothing else.', {
    label: 'local gemma retry',
    model: 'ollama/gemma4-pi',
  }),
  () => agent('Reply with exactly OPENAI_CODEX_LOW_RETRY_OK and nothing else.', {
    label: 'openai codex retry',
    model: 'openai-codex/gpt-5.4-mini:low',
  }),
])

The parent Pi process used JSON mode so the tool result and model metadata could be checked directly:

PI_CODING_AGENT_DIR="$tmp" pi --approve --mode json --print --no-session \
  --model openai-codex/gpt-5.4-mini @e2e-prompt.txt > events.jsonl

The tool_execution_end event contained two completed agents:

[
  {
    "label": "local gemma retry",
    "status": "done",
    "model": "ollama/gemma4-pi",
    "resultPreview": "LOCAL_GEMMA_CODEX_RETRY_OK"
  },
  {
    "label": "openai codex retry",
    "status": "done",
    "model": "openai-codex/gpt-5.4-mini",
    "resultPreview": "OPENAI_CODEX_LOW_RETRY_OK"
  }
]

The model fields are populated from each spawned session's resolved session.model, not copied from the requested strings. I also ran ollama ps before and after the workflow: it was empty before the run and showed gemma4-pi loaded afterward, independently confirming the local-model request.

The temporary Pi directory was deleted and Gemma was unloaded afterward.

Closes #9