Bug report (Ivvor, 2026-05-14, production River post-#242 deploy):

> Private room not working right when I invite another node. I see stuff
> like [Encrypted message - secret v1 not available (have: [0])] on
> owner node and [Encrypted message - secret v0 not available (have: [1])]
> on invited user
>
> [later] now i have a point where the owner can see everything, and the
> invited user can see new messages, but the room name is encrypted, so
> is the nickname of the owner, and the initial bunch of messages

## Root cause

When a new member joins a private room, the owner's chat-delegate
rotates the room secret to `current_version + 1` and emits
`encrypted_secrets` only at the new version. Every prior version
(v0, v1, ... new_version-1) is missing for the newly-joined member,
so they cannot decrypt:

* the room name (sealed at v0 when the owner created the room)
* the owner's nickname (sealed at v0 when set)
* any messages sent before they joined (sealed at older versions)

Owner-side appears unaffected because the owner has v0 from room
creation (UI emits it then) plus v_n from each rotation. Asymmetric
symptom on Ivvor's side: only the new version visible, history opaque.

## Fix

Extract the rotation per-member loop into a pure helper
`build_rotation_encrypted_secrets` and teach it the distinction:

* **Continuing members** (already in `previous_members`, plus the
  owner): only emit `new_version`. They already have older entries
  from the rotation that admitted them.

* **Newly-joined members** (in `current_members` but NOT in
  `previous_members`): emit every version `[0..=new_version]`. The
  older secrets are re-derived deterministically from the owner's
  signing seed via `derive_room_secret(seed, owner_vk, v)`, so the
  back-filled blobs are byte-identical to whatever the version was
  originally produced as.

The owner is always treated as continuing: at v0 the owner's own
`encrypted_secret` is emitted by the UI at room creation; on every
subsequent rotation the helper emits one fresh entry at the new
version. So the owner never needs back-fill.

## Tests

Two new regression tests in
`delegates/chat-delegate/src/subscription/tests.rs`:

* `rotation_backfills_prior_versions_for_newly_joined_members`: owner
  + alice (continuing, in `previous_members`) + bob (newly joining
  now); rotation to v2 must emit exactly `{owner@v2, alice@v2,
  bob@v0, bob@v1, bob@v2}`. Verifies owner-signature validity on each
  emitted blob, plus byte-identity on bob's back-filled v0 blob
  (re-running deterministic ECIES with the same `(secret_v0, bob_vk)`
  inputs must reproduce the exact wire bytes — pins the
  per-version secret derivation).

* `rotation_backfills_for_all_members_on_first_rotation`: empty
  `previous_members`, every current member is newly-joined and must
  receive every version up through `new_version`.

22/22 chat-delegate tests pass (was 20).

## Deploy

The delegate WASM byte-changes; V17 migration entry recorded in
`legacy_delegates.toml` so existing users transparently migrate from
the post-#242 delegate (code_hash `123f732d…` -> delegate_key
`540b2887…`) to the new one.

`room_contract.wasm` is BYTE-IDENTICAL to #242. So:

* No room contract migration ceremony needed
* No riverctl republish needed (riverctl only embeds room_contract.wasm)
* No gkapi/secrets/quickstart-URL updates needed
* Production deploy is just `cargo make publish-river`

Recovery for existing users on the buggy delegate: when this lands and
they reload the UI, the owner's delegate runs its rotation pipeline
again on the next member-set change OR existing notification, emits
the back-filled secrets, and the previously-stranded member is now
able to decrypt history.

For private rooms where membership has stabilised, the rotation
pipeline won't naturally re-fire (member set unchanged → no
rotation). In that case the owner can trigger a manual rotation by
editing the room config or banning + unbanning a member; both paths
go through UI-side `rotate_secret` which today still does the
"new version only" thing — fixing that path too is the obvious
follow-up.

[AI-assisted - Claude]

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Addresses all five PR #245 review findings.

## What was wrong with the first iteration

1. **v0 mismatch (skeptical, big-picture, codex all flagged).** The room's
   v0 secret is generated RANDOMLY by the UI in
   `ui/src/room_data.rs::create_new_room_with_name` via
   `generate_room_secret()`. The first iteration of this fix back-filled
   by RE-DERIVING via `derive_room_secret(seed, owner_vk, 0)` —
   producing a different secret. The newly-joined member would receive
   bytes that decrypted to a key unrelated to what the room name was
   sealed under. **The bug was not actually fixed.**

2. **Cache-based dedup (codex flagged).** Continuing-vs-newly-joined was
   decided from the delegate-local member-set cache. On a fresh
   delegate / restart / webapp reinstall, the cache is missing and the
   helper treats every member as newly-joined — emitting duplicate
   `(member, version)` pairs that the room contract rejects via
   `RoomSecretsV1::apply_delta`'s dedup guard, wedging rotation
   permanently.

3. **Tautological test (testing, big-picture flagged).** The regression
   test asserted byte-identity against `derive_room_secret(..., 0)` —
   the same function the broken helper called — so it would pass for
   both the broken and the correct behaviour. It never tested that
   the back-fill matched the actual on-the-wire v0.

4. **Wrong PR number in V17 description (code-first flagged).**

5. **Missing edge-case tests (testing, code-first flagged):** multiple
   simultaneous new joiners; banned-then-readmitted member.

## What this iteration does

* **Recover prior-version secrets from state, not re-derive.** The helper
  scans `new_state.secrets.encrypted_secrets` for the owner's blob at
  each prior version `v < new_version`, ECIES-decrypts it with the
  owner's signing key (which the delegate already holds for rotation),
  and recovers the actual secret bytes the room is using. New
  `decrypt_secret_from_member_blob_raw` wrapper in `common/src/ecies.rs`
  takes raw `[u8; 32]` ephemeral-pubkey bytes so the delegate doesn't
  need a direct `x25519-dalek` dep.

* **Dedup by what's already in state.** Build a `(member, version)` set
  from `existing_encrypted_secrets` and skip any pair already present.
  Continuing-vs-newly-joined is now an emergent property: a continuing
  member already has v0..v_prev entries, so only v_new is emitted; a
  newly-joined member has nothing, so they get the full back-fill.
  Works correctly even when the delegate-local cache is missing.

* **Tests pin REAL behaviour, not self-consistency:**
  - `backfill_uses_real_v0_recovered_from_owners_encrypted_secret`:
    state contains a v0 blob with random bytes; helper produces a
    back-filled v0 for bob; bob's signing key MUST decrypt the
    back-fill to the same random bytes. Asserts what the user cares
    about: bob can read the room name.
  - `backfill_handles_multiple_simultaneous_new_members`: two new
    joiners in one rotation, both back-filled, both decrypt the same
    random v0.
  - `backfill_dedups_against_state_for_continuing_members`: alice has
    v0+v1 in state; helper only emits v2 for her, no duplicates.
  - `backfill_handles_readmitted_member`: alice was removed and her
    entries cleaned up; on readmission she gets a full back-fill.

24/24 chat-delegate tests pass (was 22).

## Deploy footprint unchanged from first iteration

* Delegate WASM changes: new b3sum
  `6229c2a136b30a7868c07099efdea86bee260734339d872aa1e68177733b5fdd`.
* `room_contract.wasm` byte-identical to #242 — no room migration
  ceremony, no riverctl republish.
* V17 description text corrected (was "#243", now "#245").

[AI-assisted - Claude]

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>