Define a breaking-change process for Apps security and CSP behavior

[idosal]

Problem

Several active Apps discussions suggest broad-breaking changes (e.g., security-sensitive CSP issues), which would require coordination among several hosts and hundreds of apps.

Examples:

• Create initial proposal for apps declaring trusted types #378 proposes Trusted Types metadata for code-evaluation use cases.
• threejs-server example cannot work within current spec due to unsafe-eval #199 tracks unsafe-eval / Three.js behavior and the gap between strict spec CSP and permissive reference-host behavior.
• Support wasm-unsafe-eval CSP directive to enable WebAssembly in MCP Apps #605 / feat: add wasm-unsafe-eval CSP option #667 add explicit wasm-unsafe-eval support for WebAssembly compilation.

The spec doesn't have a defined process for introducing breaking changes, which may require broader migration planning, host coordination, compatibility windows, or versioning.

Why this matters

The spec's ability to evolve is limited so long as we're unable to change the behavior in a responsible manner.

Desired Outcome

Define a process that allows hosts and servers to reasonably adopt spec changes without breaking.