[FEATURE] Headless enqueue: send a message to a running background session (non-interactive)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I run an automated "watcher" that polls GitHub (PR review requests for me, @-mentions) and dispatches claude --bg agents to act on each thread, one session per PR/issue. On follow-up activity (a new comment, a new push), it continues the existing conversation via --bg --resume. in order to pull together all the context and get a session to the state its ready for me to weigh in. I use --bg in order to send the session into my agent view so the agent gathers work for me while i'm working in another session and when I bounce out of the session i'm on, i'll see my work queued up without breaking my flow.

Because --bg --resume starts a fresh process under a new id every time, a single actively-discussed PR accumulates a pile of sessions in claude agents (one per round of activity), each a cold reload of the full transcript. The supervisor has to chase the rotating id and clean up stragglers, and it pays the transcript-reload cost on every turn.

A headless enqueue would map far more naturally onto "a PR conversation continuing over time":

• Warm context / lower cost + latency — the running session already has the conversation loaded; no full transcript re-read per turn.
• Mid-turn interjection — if new activity arrives while the agent is still working, it can be queued for the agent to pick up when ready, instead of the supervisor having to defer or spawn a duplicate. (Right now I work around this with prompt instructions like "before posting your wrap-up, re-check the thread for new comments you're responsible for.")
• One stable session identity per logical thread, which makes tracking/observability trivial.

More broadly this benefits anything building an event-driven loop on top of background agents (webhooks, queues, schedulers, chat bridges): "an event arrived → hand it to the agent that's already on this topic."

Proposed Solution

A headless / non-interactive way to send (queue) a message into an already-running background session — something like:

claude agents send <session-id> "your message"      # enqueue a turn
# or
echo "your message" | claude agents send <session-id> --stdin

Proposed surface (sketch, open to whatever fits)

• claude agents send <session-id> <message> — enqueue a user turn; returns when accepted (not when the turn completes).
• Optional --stdin for piping larger/multiline payloads.
• Defined behavior when the target is mid-turn (queue and process after the current turn) vs. idle (process now).
• Clear error if the session id doesn't exist / isn't resumable.
• JSON output mode for scripting, consistent with claude agents --json.

Relationship to #8069

#8069 ("resume gives a different session_id") was closed NOT_PLANNED, with the reasoning that resume does correctly continue the conversation and consumers should just track the rotated id. That's reasonable for the resume model — this request is not asking to change resume's id behavior. It's asking for a distinct capability: delivering a message to a session that is still running, rather than launching a new process that reloads it. The stable-id property is a side effect, not the goal; the goal is warm continuation + mid-turn queueing for headless/automated callers.

Alternative Solutions

Today the only ways to feed a follow-up to a background agent are:

• claude attach <id> — interactive, requires a TTY/human. Not scriptable.
• claude --bg --resume <id> "<msg>" — works, but spawns a new process that cold-reloads the transcript from disk and surfaces under a new session id (per #8069, this is by-design).

There is no way for an unattended/automated supervisor to drop a message into a live, warm background session.

### Priority

High - Significant impact on productivity

### Feature Category

CLI commands and flags

### Use Case Example

I get at mentioned by my team or cloud based agents through out the day but I'm normally working directly with an agent.  For most at mentions and pr mentions i need to get context about the specific question from my coding agent which takes some time to pull the branch / search for specific details as most are architectural questions where team members are asking my opinion on a series of options.  

1. A teammate at mentions me on a new issue
2. my script listening to the at mention triggers a /bg session using a skill i have to look at that issue
3. I am working on another session in claude agents while the new session gathers context 
4. another teammate at mentions me on the issue adding some of their thoughts but i still haven't looked at the issue session waiting in my bg sessions, so the new at mention triggers my script to send a message to the existing bg session for the issue to check the issue for updates
5. I finally give me existing agent enough context where it runs for a while so i go back to the fleet view and see a session for the session on the issue i was at mentioned on that is up to date and pulled the necessary context about the open issue to help me faster feedback 

### Additional Context

_No response_