### `wai.live.coperformance`: a relay counts audience inputs in their chain's order

- **The rule** ([co-performance](extensions/co-performance.md) §7.3): a relay counts an
  author's inputs in the order of the author's chain, as a verifier does, never in the order
  they reach it. The records of one chain can reach a relay on several streams, one for each
  group, read side by side, so a member's second input could be taken before its first, and a
  relay counting as they came could forward the second and refuse the first, where a verifier
  accepts the first and refuses the second, leaving a gap in the member's chain where the first
  input was. A relay now decides an input once it has received every record of the chain below
  it and decided every input among them; it holds an input that arrives ahead of a gap, for a
  bound of its own, and refuses one whose gap has not filled by then as `input_out_of_order`,
  counting the chain from the record after it; and it refuses as `input_out_of_order` an input
  that arrives after a later input of its author was forwarded. The reason is the relay's
  alone, as `window_committed` is (§8): a verifier holds each chain in order, and `wai-rs` and
  `co_performance_verify.py` already count each input where the merged order meets it, so
  neither changes and the corpus gains no vector.
- **The relay** (`joule-moq-relay`) keeps each author's chain as it has received it, holds an
  input ahead of a gap with the rest of its stream until the gap fills or `[floor] hold_ms`
  (2 000 by default) runs out, and counts `input_out_of_order` in the session's summary.
  `tests/floor.rs`: a member's second vote, sent first on a stream of its own and held, then its
  first: the first forwarded, the second refused `input_over_limit`; and a second vote whose first
  never comes, refused `input_out_of_order` no sooner than the hold, after which the first, sent
  late, is forwarded.

