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

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:

• #378 proposes Trusted Types metadata for code-evaluation use cases.
• #199 tracks unsafe-eval / Three.js behavior and the gap between strict spec CSP and permissive reference-host behavior.
• #605 / #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.

Review the related discussions in #378, #199, #605, and #667 to identify the breaking-change patterns and compatibility concerns they raise. Define a process covering host and server coordination, migration planning, compatibility windows, and versioning, with enough guidance for adoption without unexpected breakage.