Link spin-off threads back to their originating conversation

[Dnyaneshvn]

Fixes #10.

Draft in the shape I floated on the issue, so it's easy to redirect against real code rather than in the abstract.

What was wrong

When the agent messages someone new mid-conversation ("go ask Alex about X"), the send goes out through a send tool, but nothing recorded that the new conversation was spawned from the current one. So when Alex replies, buildTextTurn routes it to a fresh session with no link back, no memory of why the thread exists, and no way to relay the answer home.

What this does

• records the conversation currently being processed for the duration of a turn's agent run, the same in-process seam channel-hint.ts already uses at dispatchInboundTurn
• when a send tool reaches a new 1:1 recipient (not the active conversation's own party, not a group, not an existing conversation id), stores a spawn link keyed by that recipient: parent session, parent reply target, and the outbound message as the "why"
• when the new recipient replies, the inbound bridge consumes the link and (a) prepends a short context block to the turn (what the thread is for, and to relay the answer back to the parent) and (b) sets modelParentSessionKey to the parent session so it inherits context, the same lever the voice path already uses
• the link is one-shot and TTL/size bounded, so an abandoned outreach can't linger and mis-parent a later, unrelated conversation with the same person

Keeps it to one small module plus the existing send and inbound seams, no new routing concepts.

Tests

• a 1:1 send to a new recipient records a spawn link with the right parent session, reply target and why
• a send to the active conversation's own party records nothing (no false parenting)
• a group send records nothing (ambiguous which recipient is the spin-off)
• when the new recipient replies, the turn carries the context block and modelParentSessionKey is set to the parent
• a reply from someone with no spawn link is unchanged (no stray context, no parent key)
• the link is one-shot: a later reply from the same person is ordinary
• recipient-key normalization for phone and email

Full suite green (352 tests).

One open choice

The parent link lives in a small module for now (mirroring channel-hint.ts / outbound-call-context.ts). Happy to move it onto the thread/session record instead if you'd prefer it there.