[FEATURE] Render MCP Apps for locally-configured MCP servers (config file / localhost or internal-network HTTP)

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

## Problem

MCP Apps (SEP-1865, `ui://` resources) only render for remote connectors on
claude.ai / Claude Desktop. Locally-configured servers never get UI rendering:

- Claude Code (CLI and VS Code extension) shows only the text result.
- Claude Desktop with a Streamable HTTP server from
`claude_desktop_config.json` or project `mcpServers` — whether on localhost
or on a company-internal host — tools work, but the UI resource is ignored
and silently falls back to text.
- Custom connectors require a publicly reachable URL. Localhost and
internal-network servers (intranet / VPN-only, not exposed to the public
internet) can't take that route, and exposing them publicly just for UI
rendering is not an option in a corporate environment.

Net effect: MCP Apps are unusable for any server behind a corporate network,
which is a large share of real MCP deployments.

## Steps to reproduce

1. Run an MCP server (Streamable HTTP, on localhost or an internal-network
host) with a tool that declares `_meta.ui.resourceUri` and a registered
`ui://` resource (`text/html;profile=mcp-app`), per the ext-apps examples.
2. Add it via config file in Claude Desktop or Claude Code.
3. Call the tool.

**Expected:** UI renders in an iframe/webview, as for remote connectors.
**Actual:** plain text result only.

### Proposed Solution

Extend MCP Apps rendering to locally-configured HTTP servers (localhost and
private-network URLs) — at minimum in Claude Desktop, ideally also in the
Claude Code VS Code extension/webviews.

### Alternative Solutions

- **Public custom connector:** not possible — the server must stay behind the
corporate firewall; exposing it (even via a tunnel like ngrok/Cloudflare)
violates company security policy.
- **Config-file server via `mcp-remote` proxy:** connects and tools work, but
the rendering path is tied to remote-connector infrastructure, so the UI
still falls back to text.
- **Plain-text/markdown tool output:** works everywhere but loses the point of
MCP Apps — no interactivity (filtering, drill-down, forms).
- **Building a separate internal web app:** duplicates the UI outside the chat
context and loses the model↔widget integration MCP Apps provide.

None of these are viable, which is why host-side support for rendering
locally-configured HTTP servers is the ask.

### Priority

High - Significant impact on productivity

### Feature Category

MCP server integration

### Use Case Example

We run an internal MCP server (Streamable HTTP) on our company network for our
ERP/operations tooling. A tool like `get_order_status` returns structured data
that is meant to render as an interactive widget — a sortable table with
filters and drill-down, defined as a `ui://` resource on the server.

The server can never be publicly reachable: it sits behind the corporate
firewall and talks to internal systems. Every employee's Claude Desktop /
Claude Code can reach it via the internal URL (e.g.
`http://mcp.internal.example:3000/mcp`), and the config-file setup connects
fine — but the widget silently degrades to a text dump, so users get a wall of
JSON instead of the UI the server ships. The only path that renders widgets
(public custom connector) is exactly the one a corporate deployment cannot use.

### Additional Context

**Similar features in other tools:** Per the MCP Apps client matrix
(https://modelcontextprotocol.io/extensions/client-matrix), other hosts
already render MCP Apps for locally-connected servers — e.g. Goose, Postman,
and MCPJam render `ui://` widgets from servers added by local URL, and VS Code
GitHub Copilot renders them in editor webviews. Claude Desktop is the outlier
in tying rendering to publicly-reachable connectors.

**Technical considerations:** Public reachability shouldn't be technically
required for rendering. The widget HTML is not fetched from the server's URL
by the browser — the host retrieves it via `resources/read` over the
already-established MCP connection and renders it in a sandboxed iframe
(`srcdoc`). That exact rendering path already exists in Claude Desktop for
remote connectors; the ask is to route config-file HTTP servers through the
same path (i.e. not exclude them via the feature-flag gate, see #88566).
The sandbox/CSP model is identical either way, since the host never contacts
the server's network location from the render surface.

**Other:** Rendering support could be gated behind an explicit opt-in setting
per server if there are trust concerns about non-directory connectors.

Start with the config-file HTTP-server path and the feature-flag gate referenced in #88566; inspect how resources/read and ui:// resources are handled for remote connectors. Done means a locally configured localhost or private-network Streamable HTTP server renders its HTML UI instead of text in Claude Desktop, with the proposed VS Code coverage clarified.

Written by the indexing model from the issue text.