Reuse cached prefixes for recipe creation, subagent fleets, and the planner

**What problem would this solve?**

Some goose requests are nearly identical to one the provider has already cached, but a few bytes differ.
The cache serves whatever prefix still matches and we pay full input price for the rest.

The reply loop already defends against this: it sorts tools before sending them, and the prompt builder sorts extensions.
Three request builders skip that convention.

1. **Recipe creation.**
`create_recipe` builds its own system prompt and tool list instead of the ones the reply loop just sent, and it strips the turn-context blocks out of the history it replays.
"Create a recipe from this session" therefore misses the session's cached prefix and re-bills the conversation.
The cost scales with the session.
2. **Subagent fleets.**
The subagent system prompt embeds the per-session `subagent_id` and lists tools in `HashMap` order (no order), so no two subagents share it.
Nothing else in that prompt varies: the task itself travels in the first user message, so a fleet could otherwise share one entry.
3. **Planner.**
`get_plan_prompt` lists tools in `HashMap` order too, so the same setup renders a different prompt in every process.

**What would a good outcome look like?**

A request that can reuse a prefix goose already sent reuses it byte for byte.
Recipe creation replays the session and appends the recipe prompt.
Subagents share one system prompt, so the first writes the cache entry and the rest read it.

**Possible approaches**

- Recipe: reuse `prepare_tools_and_prompt`, keep the turn-context blocks in the replayed history, and load the stored session conversation instead of the caller's copy.
The parts depend on each other: the blocks can stay only because the reply loop's prompt is the one that explains them.
- Subagent: sort tool names and drop `subagent_id`, which no code reads.
- Planner: sort tool names.

Sorting and dropping the ID are semantically neutral: same information, stable order.
Changing what `create_recipe` sends is not, so review should confirm recipe quality is unaffected.

- [x] I have verified this does not duplicate an existing feature request