spawn_task chip via 'cloud': prompt text arrives, but the plan behind it does not

Correction/follow-up to #98836, which mischaracterized this.

What actually happens

When a chip created by spawn_task (with a detailed prompt body) is started via the cloud avenue, the prompt text itself does reach the spawned session — that part is not dropped.

What the spawned cloud agent does not have access to is the plan/reasoning the originating session built up before writing that prompt — i.e. it's missing the working context and plan state behind the brief, not the brief's literal text. The operator observed this directly in the cloud session.

Starting the identical chip via the worktree (local) avenue instead gives the spawned session full access to that plan: in a side-by-side test, the local session not only had it, but used it to independently verify the root cause, widen the bug's scope, and produce its own GOSU spec before writing any code — behavior consistent with having real access to the planning context, not just the prompt string.

To reproduce

1. Have a session investigate something non-trivial, building up plan/context across several tool calls.
2. Call spawn_task with a prompt that summarizes that investigation.
3. Start the chip via cloud: the agent receives the prompt text but cannot act on it with the same depth — it lacks the plan/context behind it.
4. Start the same chip via worktree: the agent has full access to that context and plans/acts accordingly.

Expected behavior

Starting a chip via either avenue should give the spawned session equivalent access to the plan/context backing the prompt, not just the literal prompt string.

Note

#98836 described this as the prompt field itself not transferring. Based on direct observation, that's inaccurate — the prompt text does arrive; it's the plan/context layer that doesn't. Leaving #98836 open as a related-but-imprecise report; this issue has the corrected description.