Let an agent send a thread a message without starting a run

[bompus]

Problem

t3_thread_send always starts work. An agent that wants to leave a note on an idle thread has no way to do it without also starting a model run on that thread.

That is wrong for notes that ask for nothing, such as "the shared guidance changed in revision X, no action needed". Sending one to ten idle threads starts ten runs, and each run bills a model turn to say nothing. The sender can't tell the receiver "read this when you next run".

What I checked

I read main at b4542c5 and ran the case on a live server.

• The tool description says mode='auto' "starts an idle thread". The other modes are queue, steer and restart.
• sendToThread maps auto to start_immediately and queue to queue_after_active. It fails with a projection error if the message ends up with no run.
• CommandPolicy returns start_run for both of those when the thread has no active run.
• The result type requires a runId, and delivery can only be started, queued, steered or restarted.
• Live check: I launched an empty scratch thread (no run), then called t3_thread_send with mode: "queue". It returned delivery: "started" and the thread ran to completion.

So no mode leaves an idle thread idle.

Proposal

Add a fifth mode, for example hold, and a fifth delivery value, held. On an idle thread it records the message with its senderThreadId and starts no run. The message is delivered with the thread's next run, whoever starts it. On an active thread it behaves like queue.

The queue tools could already manage a held message: t3_queue_list, t3_queue_edit, t3_queue_cancel and t3_queue_promote_to_steer. That keeps the change small, but I don't know the queue internals well enough to say it fits.

Questions I can't answer from outside:

• Should a held message show in the thread's timeline, or only in the queue?
• Should the user see an unread marker, since the agent won't speak until it runs?
• Does a settled or snoozed thread stay settled when a note is held?

A smaller second ask

t3_thread_launch has no retry key. Its description says "Each call creates a new launch with no retry key", and the caller must list threads to avoid a duplicate after a lost response. t3_thread_send and delegate_task already take a clientRequestId, and I confirmed that a repeated send with the same id returns the same messageId and runId without a second run. A clientRequestId on t3_thread_launch would give launches the same retry behavior. Issue #16184 describes a separate problem, where the key stops working after a credential re-issue, so a launch key would inherit that fix.

Context

I use T3 Code with a separate local mail tool. Over 27 days, 222 of its 4,599 messages were quiet, informational notices that waited for the receiver to read them instead of waking it. T3 can't carry that kind of message today. I can share what I learn from using a hold mode if it helps.

Related: #6566 and discussion #7001 (sibling messaging, shipped), #17517 (the receiver can't see the sender), #16184 (retry keys across credential re-issue).