fix(ui): repopulate room_data.secrets on every state ingestion path (#251)

[sanity]

Problem

Closes #251.

When a private-room invitee subscribes, the initial GET response often arrives before the owner's chat delegate runs the PR #245 back-fill of encrypted_secrets. The back-fill ships in a subsequent state update.

The decrypt-into-room_data.secrets loop was duplicated in get_response.rs and response_handler.rs::handle_load_rooms_response, but the network-update paths in room_synchronizer.rs (apply_delta_inner and update_room_state_inner) merged the new encrypted blobs into ChatRoomStateV1 and never decrypted them into the in-memory map that the renderer reads.

Net effect (Ivvor on Matrix, 2026-05-15):

• Newly-joined member renders every message as [Encrypted message - secret v0 not available (have: [])].
• Both sides "aren't syncing" — each sends messages encrypted at a version the other doesn't have in their HashMap.
• Hard-refreshing fixes it, because reload re-runs the LoadRooms decryption loop.

Approach

Extract the decryption block into RoomData::repopulate_secrets_from_state(&mut self) -> usize:

• No-op on public rooms.
• Snapshots blobs in room_state.secrets.encrypted_secrets whose member_id == self and whose secret_version isn't already in self.secrets.
• Decrypts each, calls self.set_secret(...).
• Aligns self.current_secret_version with the contract's secrets.current_version (preserves prior get_response / load-rooms behaviour).

Call it from every state ingestion path:

• get_response.rs:178+ (initial GET) — replaces the inline duplicate.
• response_handler.rs::handle_load_rooms_response (delegate-load merge) — replaces the inline duplicate.
• room_synchronizer.rs::apply_delta_inner — new call site, before the per-private-room actions_state rebuild so newly-decrypted action messages resolve in the same tick.
• room_synchronizer.rs::update_room_state_inner — same.

The helper is idempotent (filtered by !self.secrets.contains_key(version)), so it's safe to call on every update without measurable cost on the steady-state case.

Testing

Three unit tests in ui/src/room_data.rs:

• repopulate_secrets_after_delegate_backfill_picks_up_new_blob — direct reproduction of Ivvor's repro: invitee state starts with secrets empty and encrypted_secrets empty (initial GET); first call to helper is a no-op; owner delegate back-fills the blob; second call to helper decrypts it and populates the map. Pinned the idempotency case too (third call decrypts 0).
• repopulate_secrets_skips_blobs_for_other_members — helper must not try to decrypt blobs sealed for a different member's key.
• repopulate_secrets_is_noop_on_public_room — pinned the early-return for is_private() == false.

All 95 river-ui tests pass. Workspace cargo make test green. cargo clippy clean for the touched code (no new warnings).

Manual repro will be exercised in the batched Playwright run before the next River publish.

Other items from Ivvor's report

The "memory growth" complaint is tracked separately in #246. The "owner can't send messages" sub-symptom in the 3-member case is plausibly the same bug from the owner side — owner's tab also gets stuck if a rotation-driven update arrives that brings in a new current_version for which the owner already had the secret but the apply_delta path didn't refresh current_secret_version. This patch's current_secret_version = Some(current_version) line at the end of repopulate_secrets_from_state covers that case symmetrically.

[AI-assisted - Claude]

[sanity]

Round 2 of review findings addressed in 27016a6:

Codex [P2] — Repopulate secrets for existing-room GETs. Fixed in get_response.rs::is_existing_room. Both sub-branches (imported-room wholesale-replace, existing-room merge) now call repopulate_secrets_from_state() so a refresh/suspension GET that's the first arrival of our back-filled blob populates the in-memory map.

Codex [P3] — Stale room_secrets snapshot in notifications. Fixed in both apply_delta_inner and update_room_state_inner. The pre-merge clone is gone; room_secrets is captured AFTER repopulate, so a delta carrying both a new secret AND new private messages can decrypt the notification preview correctly. update_room_state_inner's pending_notification tuple was widened to carry the secrets out of with_mut.

Testing reviewer (blocking) — regression test doesn't pin the call sites. Added repopulate_secrets_call_sites_pinned: a source-grep pin test that uses include_str! to read each ingestion-path file and assert the expected count of repopulate_secrets_from_state( call sites. Removing the call from any path fails CI. Mirrors the "source-grep pin test in the driver's test module" pattern from bug-prevention-patterns.md.

Code-first reviewer — current_secret_version downshift. Docstring expanded to explain the unconditional reassignment relies on the RoomSecretsV1 invariant (current_version == max(versions), monotonically non-decreasing under merge), so the merge that immediately precedes the call cannot move the pointer backwards.

Big-picture reviewer — AGENTS.md update. Added a bullet under "Private Room Support" documenting the in-memory-repopulation invariant and pointing future authors at the source-grep pin test.

Skeptical reviewer findings not addressed:

• M1 (corrupt-blob CPU amplification): owner is the trust root for EncryptedSecretForMemberV1 signatures; a malicious owner can already inflict worse damage than O(N) decrypts per state ingestion. Cost is bounded by the number of versions the owner has signed, which is itself bounded by rotation frequency. Not in scope for Private room: new members see encrypted-only messages until refresh — secrets HashMap not repopulated on network state updates #251.
• S2 (per-blob clone overhead): future optimization; deferred.
• S3 (cross-device rotation race): pre-existing, separate concern.

96 tests pass (the 3 new unit tests + the new pin test); clippy clean for touched code; the only remaining clippy warning in the touched region is a pre-existing type_complexity on the apply_delta_inner pending_notification tuple, not introduced by this PR.

Re-running multi-model review on the new HEAD SHA per the per-CODE-CONTENT rule.

[AI-assisted - Claude]