Let chats create new chats, not only tasks #1838

Summary

A chat's belt carries exactly one spawn tool: propose_task (internal/session/task.go:604, gated by mayProposeTask at :607). There is no way for a chat to open another chat — only the person can create conversations in the UI. Team managers get team_start, but that adds a member to an existing team's shared Traffic, not an independent new conversation.

The gap

propose_task is deliberately one-shot — its contract says the brief cannot ask anything back. That is the right shape for delegated work but the wrong shape for work that is conversational:

• a side thread that needs its own context window and its own back-and-forth (clarifying questions, staged decisions) rather than a single brief-and-report;
• parallel explorations that want to interact with the person or with each other over time;
• long-lived threads (a research diary, a watchdog conversation) that outlive one task node.

Today every one of those has to be started by hand by the person.

Ask

A propose_chat-style tool (or equivalent) letting a chat open a new chat with an opening brief, under the same guardrails propose_task already has: depth limits, admission checks, spend caps, and a checked worker. The new chat should surface in the UI the way task rows do, so the person sees who spawned it and why.

Open questions (needs a ruling)

1. Membership: can the new chat join a team as a member (manager-visible, team_send-able), or is it always standalone?
2. Backlink: does the creating chat get a handle to the new chat — and does it hear when the new chat says something, or only when it settles?
3. Spend: whose budget does the child chat draw from — the parent's, the team's, or its own?

Notes

• The depth-limit machinery (task.go:47: a node standing on taskDepthLimit is handed no propose_task at all) is the natural place to bound chaining.
• Whatever the tool is called, it must not be a thin alias of propose_task: the defining property is that the new chat can receive messages after it opens.