Late child-session messages open new top-level chats instead of returning to the parent

### Short summary

When a child session sends a message after its parent chat’s active turn has ended, the message can open a new top-level chat instead of being delivered to the existing parent.

### Affected version or release

1.0.23

### Installation context

GitHub Copilot app on Windows x64, OS build 26200.8875. General chat acting as an orchestrator with local project child sessions.

### What happened?

A parent/orchestrator general chat created a local project child session. The child initially appeared correctly nested under the parent.

The parent’s active turn later ended while the child continued working. When the child used cross-session messaging to return its result to the existing parent, the tool reported success and identified the intended parent chat. However, the result did not appear in the parent.

Instead, the app created a new top-level general chat whose first user message was the child’s result.

A later short correction sent to the same parent produced the same behavior and created another top-level chat. I did not manually create, fork, or detach either chat, and the original parent still existed.

### Steps to reproduce

This is the sequence in which I observed the issue:

1. Start a general chat and use it as an orchestrator.
2. Have the parent create a local project child session.
3. Confirm that the child initially appears nested under the parent.
4. Allow the parent’s active turn to end while the child continues working.
5. Have the child send a result back to the existing parent using cross-session messaging.
6. Inspect the original parent chat and the sidebar.

Actual:
- The result does not appear in the existing parent chat.
- A new top-level general chat is created with the result as its first message.
- A later correction sent to the same parent can create another top-level chat.

Expected:
- The result is delivered as a new turn in the existing parent chat.
- No unrelated top-level chat is created.
- The project child remains nested unless explicitly detached.

### Expected behavior

Cross-session messages addressed to an existing parent chat should be delivered into that chat, even if its previous active turn has ended.

If the parent must be resumed to process the message, the app should resume or start a new turn in the existing parent rather than creating a separate top-level chat.

### Additional context

I observed the same behavior twice within one orchestration workflow: once with a long result and once with a short correction message. I have not yet reproduced it in a separate synthetic test.

#### Possible diagnostic clue

I inspected the local session event history after the issue occurred.

In both child-to-parent `send_session_message` calls:

- The child targeted the existing parent chat.
- The tool reported success and said the message had been sent to that parent.
- The parent had previously recorded a `session.shutdown` event.
- The payload did not appear in the parent’s captured history.
- The same payload appeared byte-for-byte as the first user message of a newly created top-level general chat.
- The newly created chats had no recorded fork relationship or preceding create/fork operation.

This happened with both a long result and a short correction message.

This suggests a possible fallback or continuation-routing issue when the target parent has no active execution. It does not prove that `session.shutdown` is the cause.

Related issues:

- #898 reports unsolicited “New chat” entries, but with a different older trigger.
- #294 covers the expected hierarchical display of parent and child sessions and is closed as completed.

Raw logs are not attached because they contain local paths and session content.

Bắt đầu bằng cách tái hiện chuỗi session parent/child và kiểm tra lịch sử sự kiện session cục bộ xung quanh mỗi lần gọi send_session_message cũng như event session.shutdown của parent. So sánh đích parent dự kiến với chat top-level mới được tạo; được xem là hoàn tất khi các message tiếp tục trong parent hiện có và không có chat top-level không liên quan nào được tạo.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.