spec: decouple rendering requirements from the double-sandboxed iframe architecture #716

Description:
Currently, the MCP Apps specification is highly opinionated about how Hosts must embed Views - specifically, it mandates a "double sandboxed iframe" architecture (along with specialized sandbox-proxy-ready coordination messages).

This needlessly prevents Hosts from adopting alternative, equally secure framing architectures. For instance:

• A single sandboxed iframe served with the same CSP headers as the double iframe, but that navigates itself to a blob: URL representing the MCP App bytes, instead of injecting them into an "innermost" iframe
• A single sandboxed iframe served with the same CSP headers as above, but whose body actually streams the MCP App HTML contents directly into the iframe's parser.

Because the choice of container architecture is completely opaque to the View itself (and has zero observable compatibility impact on the messaging between the Host and View), the specification should be unopinionated on this.

Proposal: (cc @domfarolino)

We should loosen the specification to be container-agnostic. Rather than prescribing how a Host must embed an MCP App, the spec should define the core security requirements that must apply to any framing mechanism the Host might use. This includes requirements on CSP headers, sandboxing flags, allow attribute, etc.

Most of these requirements already exist in https://github.com/modelcontextprotocol/ext-apps/blob/main/specification/draft/apps.mdx#sandbox-proxy, but we could do a better job decoupling this from assumptions on the exact iframe architecture, and impose no requirements to use the reserved sandbox proxy messages.

This allow Hosts to implement whatever container architecture they prefer, so long as the relevant isolation guarantees are faithfully met.