ACP updates are not broadcast across clients

### Expected behavior

Multiple ACP clients connected to the same Goose server should receive near-real-time session updates when another client creates or updates a session.

### Observed behavior

ACP updates appear to be scoped to the client that initiated the change. Other connected clients do not receive `session/update` notifications for cross-client session creation or prompts.

### Experiment

We ran two independent ACP clients against `goose serve` over WebSocket:

- Client A initialized, called `session/list`, loaded a session, and waited for notifications.
- Client B initialized, called `session/new`, then sent `session/prompt` to that same session.

Client B received `session/update` events for its own actions, including assistant streaming chunks. Client A received no events after `session/new` and no events during or after Client B’s `session/prompt`.

We observed the same behavior with separate stdio `goose acp` processes.

### Impact

Remote/mobile ACP clients cannot reflect sessions or messages created by another Goose client without polling `session/list` and replaying `session/load`. This makes near-real-time cross-client session sync difficult to implement cleanly.

Look at the WebSocket server implementation in `goose serve` and the ACP protocol handling for session updates. The issue is about broadcast notifications across connected clients. Start by finding where `session/update` events are generated and sent, likely in a session management module. Check if there's a central pub/sub mechanism or client registry. The test case described can be reproduced with two `goose acp` processes. 'Done' means both clients receive updates for sessions created or modified by the other.

由索引模型根据 Issue 内容生成。