Fix: vault embeds now open — via the host's embed protocol, automatically

• The bug. The embedded demos showed the vault host's key-entry form (R0 W0) instead of the vault. The /#key flow saves the key to localStorage and redirects — and localStorage at the vault host is partitioned by top-level origin in modern browsers, so inside a cross-site iframe the save is lost and the app page finds no key. Diagnosed by reading the host's own vault-loader source, which documents exactly this case.
• The fix. The embeds now use the host's purpose-built embed mode (/en-gb/app/?embed=1) and its postMessage handshake: the vault signals vault-embed-ready, the page answers vault-open with the published read key targeted at the vault's origin (never *), and vault-ready flips a visible status chip to Live · read-only. The key never appears in the iframe URL and is held in memory only — strictly better than the fragment flow it replaces. Open-in-its-own-tab links keep the fragment, which works top-level where storage is first-party.
• The demos open automatically with the page (no click gate), per the project lead — the vault assets are cached, and the deferred-loading attribute still keeps below-the-fold embeds idle until scrolled near. If a handshake never arrives (frame blocked, storage-hostile browser), the status says so after 15s and points at the tab link rather than spinning forever.
• The smoke drives the actual handshake — ready → key → live — and asserts the key is never in an iframe URL, is targeted at the vault origin, and that signals from unknown frames are ignored.