feat: Support MCP resources/subscribe and notifications/resources/updated

### Context

This builds directly on #1803 (`resources/read`) and #1518 (resources & prompts).

Among the remaining MCP primitives, **resource subscriptions** are a particularly
high-impact missing piece for autonomous agent workflows because they allow MCP
servers to notify clients about resource changes without polling.

#1378 suggests that Copilot CLI already has infrastructure for MCP server-push
notifications via `notifications/tools/list_changed`. The same notification
dispatch path seems like the natural place to add resource update handling.

### What's missing

| Protocol message | Direction | Status |
|------------------|-----------|--------|
| `resources/subscribe` | client → server | ❌ not sent |
| `notifications/resources/updated` | server → client | ❌ not handled |
| `resources/unsubscribe` | client → server | ❌ not sent |

### Proposed minimal addition

Once `resources/read` is supported (#1803), Copilot CLI could add support for
resource subscriptions with a small extension to the MCP client layer:

```typescript
// When the agent receives or selects a watchable resource URI,
// subscribe if the server supports resource subscriptions.
if (serverCapabilities?.resources?.subscribe && resourceUri) {
await mcpClient.subscribeResource({ uri: resourceUri });
}

// Handle resource update notifications alongside the existing
// tools/list_changed notification handler.
mcpClient.setNotificationHandler('notifications/resources/updated', async (n) => {
const { uri } = n.params;
const { contents } = await mcpClient.readResource({ uri });

// Surface the updated contents to the agent/session context.
agentContext.injectResourceUpdate(uri, contents);
});
```

This is a straightforward extension: `resources/read` (#1803) is the only
prerequisite for re-reading the updated resource contents.

### Why this matters

Without resource subscriptions, long-running MCP workflows must either poll
resources/tools repeatedly or expose extra status-check tools.

With subscriptions, an MCP server can expose a watch resource, notify the client
when the resource changes, and let the client re-read the resource only when
needed.

Example flow:

1. Server exposes a watch resource such as `copilot-review://watch/{id}`
2. Client reads the resource and sees a pending state
3. Client subscribes with `resources/subscribe`
4. Server sends `notifications/resources/updated` when the state changes
5. Client re-reads the resource and continues without polling
6. Client calls `resources/unsubscribe` when done

### Related issues

* #1803 — Support MCP `resources/read` primitive (prerequisite)
* #1518 — Support MCP resources and prompts (broader tracking issue)
* #1378 — `notifications/tools/list_changed` handling (existing notification infrastructure)

Start by reviewing the MCP client layer and the existing notifications/tools/list_changed handling described in #1378, then confirm the resources/read prerequisite in #1803. Trace how resource capabilities and notification handlers are represented. Done means sending resources/subscribe and resources/unsubscribe, handling notifications/resources/updated, and re-reading and surfacing the changed resource.

由索引模型根據 Issue 內容生成。