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](https://github.com/github/copilot-cli/issues/3344)
- [Queued user messages and system notifications delivered out of send order](https://github.com/github/copilot-cli/issues/3517)
- [Project sessions hide context-exhausted and interrupted turn causes](https://github.com/github/copilot-cli/issues/4144)
- [Plan approval in autopilot+fleet mode triggers a dispatch ordering mismatch](https://github.com/github/copilot-cli/issues/2833)

Start by tracing the get_session and list_sessions_and_chats API paths, then read the related queue and session-state reports linked in the issue. Define the state and generation semantics needed for a coordinator to verify that a child has no active or queued work before merging, and document what acknowledgment makes the barrier complete.

Written by the indexing model from the issue text.