Expose queued and active processing state for project sessions

Describe the feature or problem you'd like to solve

Project-session coordination APIs do not expose whether a child session is actively processing or still has queued user messages. A parent can receive a completion handoff and see static branch/diff metadata from get_session, yet remain unable to prove the child is drained before merging its pull request.

This creates a cross-session merge race: if the parent previously sent a follow-up that is still queued, the child can wake after the parent merges, process that message, and push a trailing commit to the already-merged branch.

Proposed solution

Expose explicit processing and queue state in get_session and list_sessions_and_chats, for example:

• is_processing: boolean
• queued_messages_count: number
• the current/last processed message identifier or a monotonic drain generation

Provide a native way for a coordinator to establish a merge barrier: wait until the child reports no active turn and no queued messages, then send a final stop/ready request and verify its acknowledgment belongs to the latest queue generation.

This would make project-session orchestration safe without relying only on conversational conventions or guessing from updated_at.

Example prompts or workflows

1. A parent asks a child to implement a PR, sends two review fixes, then checks is_processing == false and queued_messages_count == 0 before merging.
2. A parent sends “Make no further changes; reply READY_FOR_MERGE,” then verifies the reply drained the latest queue generation before running gh pr merge.
3. An orchestration dashboard shows which child sessions are idle, actively processing, or waiting on queued input.
4. A parent avoids archiving a child that still has pending messages even though its latest task handoff is complete.

Additional context

Observed workflow: a child reported a validated PR head; the parent independently reviewed and merged it. A previously queued follow-up then woke the child, which produced and pushed a test-only commit after merge. The child detected the race and stopped, but the parent had no API field that could have prevented it.

Related queue/session-state reports do not expose a coordinator merge barrier:

• Messages submitted while background subagents are running get stranded in the Queued UI region
• Queued user messages and system notifications delivered out of send order
• Project sessions hide context-exhausted and interrupted turn causes
• Plan approval in autopilot+fleet mode triggers a dispatch ordering mismatch

Commencez par suivre les chemins d’API get_session et list_sessions_and_chats, puis lisez les rapports associés sur la file d’attente et l’état de session liés dans l’issue. Définissez la sémantique de l’état et de la génération dont un coordinator a besoin pour vérifier qu’un child n’a aucun travail actif ou en attente avant la fusion, et documentez quel accusé de réception rend la barrière complète.