### `wai.live.remote`: what a controller types is sealed to the host

- **Sealed actions** ([remote-desktop](extensions/remote-desktop.md) §5.5): a host states a
  sealing key, an X25519 public key, as the screen statement's last field (`seal`; a statement
  without it reads as before). A controller seals every key, text and clipboard action to it: the
  action becomes type 8, `sealed`, which keeps in the clear the type it seals, its `dt_us`, a
  clipboard text's length and a commitment, and the input statement ends with one HPKE seal of
  every sealed action's opening (a 16-byte salt and its fields, a text padded to 64 bytes),
  RFC 9180 base mode with DHKEM(X25519, HKDF-SHA256), HKDF-SHA256 and AES-128-GCM, its `aad`
  the author's key and the statement's clear part. The commitment, SHA-256 over the room, the
  author, the host, the screen statement, the action's index and instant, the type it seals and
  its opening, binds the input, its order and its author. Pointer, wheel and touch actions stay
  in the clear. Every other field of every record is as it was.
- **Two rules and two levels**: §5.3 gains rule 8, `input_unsealed` (a key, text or clipboard
  action in the clear to a screen with a sealing key), and rule 9, `input_bad_seal` (a seal to a
  screen with no sealing key, or one that does not open, read or keep its commitments, whose four
  reasons are §12's new fourth table). A verification at the commitment level reads no plaintext
  and checks every outcome against rules 1 to 8, and rule 9 where the screen has no sealing key;
  one at the opened level, given the host's opening key, opens every seal, makes all nine rules
  and states each sealed input opened or why not (§11.4). An outcome's `reason` runs to 9; a
  host's totals state rules 8 and 9 where they are not zero.
- **The reference** (`wai-rs`): `Input::seal`, `Input::open`, `remote_desktop::commitment`,
  `decide_opened` (all nine rules, the actions to inject) and `verify_opened`; HPKE moves from
  `telemetry_aggregate` to a crate module behind its own feature, `hpke`, which both use. The
  corpus keeps its 42 vectors byte for byte and appends ten sealed ones, each stating the opened
  level beside the commitment level, among them a seal to the wrong key and a commitment that
  does not match; `remote_desktop_verify.py` checks both levels, opening every seal with the
  aggregation verifier's HPKE.
- **The host agent** makes a sealing key for each session, states it, and opens every sealed
  input before it injects it (`--opening-key` writes the session's opening key for a verifier);
  its headless viewer seals; and it reaches the room service over `https://` and the relay over
  `wss://`, verifying each certificate against the system's roots and any `--ca` file. **The room
  page** seals what it sends, never sends a key, text or clipboard action in the clear, and shows
  a viewer that a controller is typing, never what. **The room service's clock** bounds the
  records it holds of a session, per principal first (§10): at `[remote]
  max_records_per_principal` (100000 by default) it cuts and removes the principal that reached
  it (`leave` reason 2) and the session goes on, the host cutting it at the same record; at
  `max_records` (1000000 by default, ten times the bound per principal) it ends the session,
  every principal's `leave` signed, and states why.

