Surface per-server MCP Apps capability on McpServersLoadedServer / SessionMcpServerStatusChangedData

### Summary

`McpServersLoadedServer` (from `session.mcp_servers_loaded`) and `SessionMcpServerStatusChangedData` (from `session.mcp_server_status_changed`) describe each MCP server's `name`, `status`, `transport`, `source`, plugin info, and `error`, but carry nothing indicating whether that specific server is **MCP Apps (SEP-1865) capable** (i.e. exposes UI resources). A consumer that models capability per server has no direct signal at that granularity.

### Current state

MCP Apps capability is observable at two other granularities today, just not per-server:

- **Session-wide** — `CapabilitiesChangedUI.mcp_apps` ("Whether MCP Apps (SEP-1865) UI passthrough is now supported") and `session_has_mcp_apps`.
- **Per-tool** — tool definition metadata `ui` ("present for MCP tools with MCP Apps support").

The per-server status types, however, expose no equivalent:

```rust
pub struct McpServersLoadedServer {
pub error: Option,
pub name: String,
pub plugin_name: Option,
pub plugin_version: Option,
pub source: Option,
pub status: McpServerStatus,
pub transport: Option,
// no MCP-Apps capability field
}
```

### Consequence

A consumer that wants to advertise, in its own surface, *which configured MCP servers offer App/UI experiences* has to infer it indirectly — e.g. by scanning every tool of every server for `ui` metadata — instead of reading a per-server flag. The capability granularity (session / tool) doesn't line up with a per-server model.

### Suggested fix

Add an optional per-server MCP-Apps capability flag to `McpServersLoadedServer` (and ideally `SessionMcpServerStatusChangedData`), so consumers can read App-capability at the server granularity directly. Alternatively, if the intended model is that App capability is strictly per-tool, documenting that explicitly on these types would resolve the ambiguity.

Bắt đầu bằng cách tìm các định nghĩa của McpServersLoadedServer và SessionMcpServerStatusChangedData, sau đó so sánh các trường hiện có của chúng với CapabilitiesChangedUI.mcp_apps trên toàn session và metadata UI theo từng tool. Được xem là hoàn tất khi mô hình capability theo từng server dự kiến đã được xác định và cả hai kiểu trạng thái đều expose signal đó, hoặc các kiểu này ghi rõ trong tài liệu rằng capability vẫn được áp dụng theo từng tool.

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