## 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.