Workflow script API: no way to continue a previously spawned agent

The Workflow tool's script API has one agent primitive, `agent(prompt, opts)`, which is one-shot. It returns a result and the script can never address that agent again. This forces every multi-pass workflow to re-spawn agents that then rebuild context the previous agent already had.

## Measured cost

A delivery pipeline that implements a change, reviews it, then runs fix rounds against the findings. Per-agent, from the run transcripts:

| agent | turns | output | cache read |
|---|---|---|---|
| implementer | 83 | 15.4k | 4.40M |
| fix round 1 | 105 | 28.4k | 6.44M |
| fix round 2 | 39 | 5.5k | 1.34M |

The fix round costs more than the implementation it is fixing, on a one-line change, because it re-reads the diff, the findings and the surrounding code and re-runs the suites before it can start.

A second run of the same pipeline repeats the shape: implementer 103 turns / 7.6M cache read, then three fix rounds at 101 / 8.4M, 101 / 7.1M and 45 / 1.8M. That run moved roughly 46M cache-read tokens against 257k of output, so the spend is context reconstruction, not reasoning.

## The runtime already supports what is needed

A main session spawns agents with `Agent` and continues them with `SendMessage`, context intact, until stopped. The gap is only in the script surface.

Probing from inside a workflow subagent: its tools are `Bash, Edit, ListAgents, Read, ReportFindings, Skill, ToolSearch, StructuredOutput`; `ToolSearch select:Agent,Task` returns no match; `SendMessage` is reachable through `ToolSearch`, but `ListAgents` from a subagent lists sessions, never sibling workflow agents, so a concurrent sibling is invisible and unaddressable. Parking an agent on a no-op and messaging it from another agent is therefore not a workaround.

## Request

A way for a script to continue an agent it spawned. Either `agent()` returns a handle that can be called again, or `opts.name` makes it addressable and a `continue(name, prompt)` hook exists.

## The hard part, acknowledged

Resume is keyed on `(prompt, opts)` per `agent()` call, and a continued agent has no single prompt, so caching a multi-turn agent is a real design question rather than an oversight. A partial answer would still help: even a continuation that is explicitly non-resumable, and forces a re-run of that agent on resume, would be worth it at these numbers.

Start by tracing the Workflow tool's script API around agent(prompt, opts), then compare it with the runtime paths that expose Agent and SendMessage. The issue is done when scripts can continue a previously spawned agent, either by a returned handle or a named continue hook, with an explicit decision about how that interacts with resume caching.

Written by the indexing model from the issue text.