feat(common): deterministic room secret derivation

[sanity]

Problem

Re-enabling private rooms with delegate-driven secret rotation (#228) requires multiple replicas of the same chat delegate (e.g. a user running River on laptop and phone) to compute byte-identical room secrets without coordination. Today, rotation generates a fresh random secret in RoomData::rotate_secret (ui/src/room_data.rs:441), which means two replicas rotating concurrently produce divergent state. This blocks the delegate-driven architecture described in #228.

We need a deterministic key-derivation function keyed on the owner's signing key seed, with proper domain separation so secrets don't collide across rooms or rotation versions.

Approach

Add a single pure helper, common::key_derivation::derive_room_secret. It uses a two-phase blake3 construction:

let root = blake3::derive_key(ROOT_CONTEXT, signing_key_seed);
let mut hasher = blake3::Hasher::new_keyed(&root);
hasher.update(owner_vk.as_bytes());
hasher.update(&version.to_le_bytes());
*hasher.finalize().as_bytes()

Phase 1 (blake3::derive_key) is the canonical blake3 KDF mode with a hard-coded context string ("river-rotate v1 2026-04 room-secret-root"). Phase 2 keyed-hash mixes in the per-call inputs. Splitting these phases means a future protocol-version bump just changes the context string, and a future input addition is confined to phase 2 — both make a wire-format break visible at code-review time rather than silent.

The function is intentionally unused in this PR; PR 2 will wire it into RoomData::rotate_secret (a TODO(#228 PR 2) marker is included at the swap site). Splitting derivation from wiring keeps the cryptographic construction easy to scrutinize independently.

Why not derive directly from signing_key?

An earlier draft proposed a separate rotation_seed. The supposed benefit was compromise recovery, but in practice signing-key compromise is already terminal (the attacker controls the room identity), and a separate seed adds state without a realistic recovery scenario. Direct derivation from the signing key seed is simpler with the same effective security. See #228 for the full reasoning.

Trade-off

Anyone with the signing key seed can derive every past and future secret. This is acceptable for River's threat model — the signing key already authorises every room operation — and buys multi-device determinism without distributed coordination. A removed member who held secret_v_n cannot derive secret_v_{n+1} (they don't have the seed), so forward secrecy against removed members holds. Apps that need historical forward secrecy against signing-key compromise must not use this construction.

Testing

Eight unit tests in common/src/key_derivation.rs:

• derive_is_deterministic — same inputs produce same output
• derive_separates_versions — different versions produce different outputs
• derive_separates_owners — different owners produce different outputs
• derive_separates_keys — different signing key seeds produce different outputs
• derive_locks_input_ordering — locks the order of update(owner_vk) vs update(version) (catches argument-swap regressions)
• derive_known_answer_v1_zero_seed_zero_version — KAT for seed = [0u8; 32], version = 0
• derive_known_answer_v1_multi_byte_version — KAT for version = 0x01020304 (catches to_le_bytes to to_be_bytes regressions)
• derive_known_answer_v1_all_ff_seed — KAT for seed = [0xFFu8; 32] (exercises non-zero key bytes)

The KAT comment includes a Python blake3 snippet for independent verification — vectors can be regenerated outside the implementation-under-test if needed.

cargo test -p river-core: 192 passed, 0 failed.
cargo clippy -p river-core --all-targets --all-features: clean.

No delegate or contract WASM changes (function is dead code; baseline hashes preserved). cargo make check-migration: "Committed WASM matches HEAD — no migration needed."

Review

This PR was reviewed by four parallel internal review agents (code-first, testing, skeptical, big-picture) per the multi-model-review rule. No blockers were raised; the second commit on this branch addresses consensus suggestions:

• Construction hardening (two-phase blake3 KDF replacing single-phase keyed-hash; closes the concatenation-fragility concern raised by code-first and skeptical reviewers).
• Documented signing_key_seed invariants explicitly.
• Documented the security trade-off in the docstring.
• Added cross-axis swap test and two additional KAT vectors per the testing reviewer.
• Added external-verification recipe to the KAT comment per the big-picture reviewer.
• Added a TODO(#228 PR 2) marker at the planned swap site.

Closes #228 partial — derivation helper only; rotation wiring follows in PR 2.

[AI-assisted - Claude]