Agents session disappears after switching away from a failed session with an active fork

- Copilot Chat Extension Version: 0.59.2026072302
- VS Code Version: 1.131.0-insider (9aab2f51076649ada9d3d8412558fd1484dd5f04, arm64)
- OS Version: macOS 26.5.2
- Feature (e.g. agent/edit/ask mode): Agents window, Copilot CLI multi-chat/forked chat, Sessions sidebar
- Selected model (e.g. GPT 4.1, Claude 3.7 Sonnet): GPT-5.6 Sol
- Logs: Reproduced and correlated in local Agent Host, AHP, renderer, and profile-storage logs. Relevant event sequence and conclusions are included below.

Steps to Reproduce:

1. In the Agents window Sessions filter, leave **Failed** unchecked (the persisted profile value is `sessionsListControl.excludedStatuses = [4]`, where `4` is UI `SessionStatus.Error`).
2. Open a Copilot CLI session and let its default/main chat fail.
3. Fork the chat before the failure point and continue working in the fork so the peer chat is actively `InProgress`.
4. Observe that the active session remains visible in the sidebar, but its row is labelled **Failed** even while the fork is running.
5. Switch to another session.
6. Observe that the original session immediately disappears from the Sessions sidebar.
7. Re-enable **Failed** or reset the Sessions filters; the session reappears.

## Expected

A running peer/fork chat should promote the aggregate session status to `InProgress`, matching the Sessions contract (`NeedsInput > InProgress > other`). Switching away should therefore leave the still-running session visible when only Failed sessions are excluded.

See - https://vscodeteam.slack.com/archives/C09MVCZKLP4/p1784823824073999?thread_ts=1784823693.032779&cid=C09MVCZKLP4

## Actual

The aggregate session remains `Error` while the peer chat is running. Because Failed sessions are excluded, the row is visible only while active and disappears as soon as another session becomes active. This looks like destructive session loss, although the session, chats, and worktree are still present.

## Root Cause Analysis

There are three interacting behaviors:

1. `AgentHostStateManager._aggregateChatSummaries` in `src/vs/platform/agentHost/node/agentHostStateManager.ts` checks `errorChat` before `inProgressChat`, giving the effective precedence `InputNeeded > Error > InProgress`. When the default chat has failed and a peer fork starts streaming, the session summary therefore remains `Error`.
2. `SessionsList.update` in `src/vs/sessions/contrib/sessions/browser/views/sessionsList.ts` filters sessions whose status is in `excludedStatuses`.
3. The same method deliberately reinserts a filtered session while it is active. Once the user switches sessions, that exception no longer applies and the Error-status session vanishes from the list.

The multi-chat status implementation conflicts with `src/vs/sessions/SESSIONS.md`, which documents `NeedsInput > InProgress > other`. Existing tests cover a running peer with an **idle** default chat, but not a running peer with an **errored** default chat.

## Log Evidence

- The default chat transitioned to protocol `Error`.
- The forked peer chat subsequently transitioned to protocol `InProgress`.
- No aggregate session-summary transition to `InProgress` was emitted while the fork ran.
- A later `listSessions` response still contained the session with `Error | IsRead`; there was no delete, archive, or dispose request.

## Suggested Fix

Change the aggregate precedence to `InputNeeded > InProgress > Error`, then add a regression test where:

1. the default chat is Error;
2. a peer chat starts and the session becomes InProgress;
3. the peer completes and the session falls back to Error.

A secondary UX improvement would be to make active status filters more obvious, since the active-session exception currently masks the filter until navigation.