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.