fix: make transfer_task concurrency-safe under parallel tool calls

[bernard-code-lab]

Fixes #4156

Problem

When a model issues several transfer_task calls in one API response, Dispatcher.Process runs them in parallel goroutines via concurrent.MapSlice. Each goroutine re-resolved its caller through resolveSessionAgent, which reads the shared agentRouter.current that a sibling's swapCurrentAgent had already mutated:

T1: resolveSessionAgent(sess) -> "orchestrator"  -> validates OK
    runForwarding -> swapCurrentAgent -> current = "drafter"
T2: resolveSessionAgent(sess) -> "drafter"       <- reads the mutated value
    validateAgentInList("drafter", "drafter", ...) -> FAIL

The reported symptom is the loud one:

Agent drafter cannot transfer task to drafter: target agent not in sub-agents list.
No agents are configured in this list.

There is a quieter consequence too. runForwarding only pins the child session when the parent is already pinned, so a foreground delegation's child stays unpinned and loop.go re-resolves its agent from current on every iteration. With the deferred restores interleaving, a child could execute turns with another sibling's identity, toolset and model — no error, wrong output. validateDelegation inherits the same wrong caller, which can also produce a spurious delegation cycle detected.

atomic.Pointer keeps current free of data races, but it cannot make the read → validate → mutate → read sequence serializable.

Fix

Two orthogonal changes.

1. Resolve the caller from the batch snapshot. Dispatcher.Process already resolves the caller exactly once, before the fan-out, and stores it on the call that backs every handler's tools.Runtime. It just was not reachable. callRuntime now exposes it, and LocalRuntime.callerAgent prefers it over session resolution, falling back for hosts that provide no snapshot. No handler signature changes — rt tools.Runtime was already a parameter of ToolHandlerFunc.

2. Let one delegation own the shared current agent. runForwarding claims it with a CAS; a sibling that loses the claim pins its child instead of stomping the swap. This is the same isolation mode background delegations already use.

run_skill shares runForwarding and had the same latent defect when it landed in a batch alongside transfer_task; the same change fixes it.

Behavior change

With a single transfer_task in the batch — the common case — behavior is unchanged: the swap happens, the child stays unpinned, and the existing foreground tests pass untouched.

With N parallel transfers, the 2nd..Nth child is pinned. Pinned children do not take the handoff / force_handoff path (loop.go guards on sess.AgentName == ""). That is a pre-existing property of pinning, now reachable in a new scenario, and it is documented on SwitchCurrentAgent. If you would rather have no variance between the single and parallel cases, the alternative is to pin every child whenever the batch holds more than one delegation — same trade, but it gives up the untouched single-transfer path.

Out of scope

run_background_agent resolves its caller the same way, but agenttool.Handler.HandleRun does not receive a tools.Runtime, so fixing it means changing a signature outside pkg/runtime. Left for a follow-up; its children are already pinned, which bounds the impact.

Testing

Two regression tests, both verified to fail with the source changes reverted:

• TestTransferTask_UsesBatchCallerSnapshotNotSharedCurrentAgent — deterministic, reproduces the exact error string from the issue.
• TestTransferTask_ConcurrentForegroundTransfersStayIsolated — end-to-end through RunStream → Dispatcher.Process → concurrent.MapSlice, with three transfer_task calls in one assistant response. Without the fix two of the three children return no output and the race detector fires on a shared test stream, which is the cross-wiring made visible: two children had resolved to the same agent. With the fix it is stable over 20 runs under -race.

go build ./...                    Success
go test -race ./pkg/runtime/...   1141 passed
go test ./...                     6003 passed, 90 packages
golangci-lint run                 0 issues
go run ./lint .                   1929 files, no offenses
go mod tidy --diff                clean

task lint / task test were run as their underlying commands, since task is not installed locally.

[aheritier]

👋 Some commits in this PR are not signed and verified by GitHub. Please sign your commits with a GPG or SSH key registered in your GitHub account, then force-push.

Commits that are not verified: 7b3dc36

See GitHub's guide on signing commits for setup instructions. I've added status/needs-signed-commits; it will be removed automatically once every commit in this PR carries a valid GitHub-verified signature.