fix(common): stop the messages/DM prune-resend loop with retention horizons

[sanity]

Problem

This is a CORRECTNESS fix, not a bandwidth fix. Deltas are 0.9% of the Freenet Official room's wire bytes; the other 99.15% is full-state sends. This PR operates only on deltas, so it does not address the bandwidth incident that prompted it, and it should not be merged in the belief that it will. The remedy for that lives in freenet-core's full-state fan-out, not in the room contract.

What it does fix is real and worth fixing on its own terms: a gossip exchange that never terminates. See "Why this is still worth merging" below.

Scope: this fixes the CAP-DRIVEN prune/resend loop only. It does NOT fix the other channels that share the same shape — see "Not fixed here".

ComposableState convergence assumes merge is a join: state grows toward a least upper bound, so delta eventually returns None and fan-out stops. Two collections in ChatRoomStateV1 break that by removing entries in apply_delta:

• MessagesV1 drains the oldest messages over max_recent_messages (message.rs:230-233).
• DirectMessagesV1 capped each ordered (sender, recipient) pair at MAX_DM_MESSAGES_PER_PAIR, first-come-wins.

delta was a pure "everything you don't have" set-difference and Summary carried no prune horizon, so a peer whose retained window differed from its neighbour's offered exactly the entries the neighbour discards. The receiver applied them, pruned straight back, and its summary never changed — so the sender, which cannot see the rejection, computed the identical payload again on the next fan-out. delta never returned None, so freenet-core's "empty delta → skip" path never fired.

How long it persists depends on whether the peers agree on max_recent_messages. An earlier draft of this description said the loop runs "forever" unconditionally. That is wrong and has been corrected:

• Equal caps — each direction loops (the sender cannot see the rejection), but a bidirectional exchange heals the pair: the lagging peer learns the newer messages and its stale window prunes itself away. An 8-peer simulation converged in 16 sends. So under equal caps this is bounded waste, not a permanent loop.
• Unequal caps — permanent non-healing requires the two peers to DISAGREE on max_recent_messages. max_recent_messages is per-room configuration read from parent_state, so a config update that has reached one peer and not another produces exactly this.

The regression tests drive only the direction that persists, which is why they are one-directional loop detectors rather than convergence tests.

Measured impact — small, and measured rather than inferred

Telemetry from broadcast_payload_mix on v0.2.106 (1,319 peers, 291 emitting, 7,621 rollup windows, segmented on service.version):

	full-state	delta
fleet-wide, share of wire bytes	95.58%	4.42%
Freenet Official room	99.15%	0.9%

The room figure is isolated to 204 windows where the room is provably the only contract with attributed full-state bytes. Full-state sends are ~254 KB each — matching the state size, and explaining the "~370 KB payload" reports — against ~881 B per delta send. The room accounts for 23.2 GB, 46.9% of all attributed full-state bytes network-wide.

This PR operates only on deltas. The cap-driven loop it fixes, and the ban-purge and BansV1 channels it does not, all live inside that 0.9%. Fixing it will not produce a visible traffic reduction.

And the outbound leg deliberately gets no horizon benefit at all. outbound_summary neutralises both horizons on the send path (see the fix note below), so an outgoing update is the plain id-set difference against last_synced_state. Because update_room_state_inner does not call sync_info.state_updated, that baseline stays stale after an inbound full state, and the next tick re-offers current-minus-baseline unfiltered. This matches main, so it is NOT a regression and it cannot loop — the baseline only ever grows toward the state — but it means the horizon's saving applies to the RECEIVE path only. The already-small delta share above should be read with that in mind rather than as an upper bound the horizon fully captures.

Withdrawn claims. Two earlier drafts of this description overstated the impact and neither figure should be repeated:

1. A network-wide share-of-broadcast-work figure derived from a state_size-weighted proxy. state_size is the post-apply FULL state, logged whether a delta or a full state actually crossed the wire, so it structurally overweights any large-state contract and cannot be attributed to this bug at all.
2. A "14.3% of sends / 16.3% of delta bytes" steady-state waste rate. That is the waste rate within deltas, so it must be scaled by the delta share: 16.3% of 0.9% is not a bandwidth win. Those numbers are retained below only as evidence the loop is real, never as an impact claim.

Why this is still worth merging

The defect is a non-terminating gossip exchange, and it is empirically reproduced against the live deployed contract: a 14,989-byte non-empty delta applied with the state hash IDENTICAL before and after, 5 rounds out of 5. The receiver accepts the payload, prunes it straight back, its summary is unchanged, and the sender recomputes the same bytes indefinitely. Within deltas the steady-state waste at the room's real cap of 50 measures 14.3% of sends and 16.3% of delta bytes — cited here as confirmation that the loop is live and sustained, not as a bandwidth argument.

A merge operation that never reaches a fixpoint is a correctness bug in a CRDT regardless of how many bytes it currently moves, and it is the kind that gets worse silently as caps and room sizes change. The fix is small, the mechanism is proven, and the test coverage is unusually strong (16 mutation-verified properties plus 14 scenario tests).

Open contradiction, tracked separately

83.1% of this room's full-state bytes are attributed to the is_delta_efficient gate refusing — yet the room measures 33,804 B summary against 251,887 B state (13.4%, well under the 50% threshold), and no constructible state trips it. That is unresolved and is being chased in freenet-core, not here. Recorded so the trail is not lost.

Approach

Publish the receiver's retention horizon in its summary, and have the sender filter to entries the receiver would actually keep.

• MessagesV1::Summary becomes { message_ids: BTreeSet<MessageId>, horizon }. RetentionHorizon is Open (below cap), OldestRetained(key) (at cap), or Closed (max_recent_messages == 0 — reachable via a full-state PUT, since verify does not reject a zero cap the way apply_delta does).

• DirectMessagesSummary gains sorted pair_horizons, one per at-capacity pair.

• The DM per-pair cap becomes newest-N instead of first-come-wins. First-come was order-dependent, so two peers at the cap could hold different sets forever; it also silently dropped every later DM once a pair filled up, which was a user-visible bug on its own.

  User-visible behaviour change, intended but worth calling out: the old rule kept the FIRST 100 messages per ordered pair; the new one keeps the NEWEST 100. Any pair already sitting at 100 will therefore start evicting its OLDEST DMs on the first merge after migration. Users of such a pair will see old DMs disappear. This is the correct behaviour — a chat that silently discards everything you send after the hundredth message is worse — but it is a visible change, not a silent no-op. (Not currently reached in the Freenet Official room: its busiest pair holds 25.)

Why it terminates. The horizon is the minimum held key, published only at capacity, so it never over-states — a sender is never told to withhold something the receiver would have kept. Under-stating costs one round. Applying any offered entry pushes the peer over capacity, so the prune drops at least the horizon entry itself and the horizon strictly increases; a peer below capacity discards nothing and its id set only grows. Each exchange either grows a bounded set or strictly advances a bounded key.

max_recent_messages is read from parent_state, so this is per-room config, not a constant, and peers may legitimately differ.

Summaries stay deterministic (BTreeSet / sorted Vec, never HashMap/HashSet) per .claude/rules/contract-summary-determinism.md.

UI: merge can no longer take a sentinel parent

MessagesV1::summarize now reads parent_state, retiring the invariant room_synchronizer relied on to pass a cheap ChatRoomStateV1::default(). Under the sentinel it reads the DEFAULT cap (100) instead of the room's, advertises an open horizon, and re-opens the loop.

Replaced with merge_incoming_state, which unrolls merge so summarize gets the room's own state while apply_delta keeps the sentinel (the macro ignores its outer parent_state there) — so no clone is reintroduced and the #246 saving stands.

The old equivalence pin merge_with_default_sentinel_parent_matches_merge_with_self_clone_parent is replaced by merge_uses_room_state_as_parent_so_horizon_is_correct, which asserts on the delta, not the state: the final state is identical either way, so a state-equality assertion structurally cannot catch this regression.

That replacement covers the summarize leg ONLY. It drives merge_incoming_state on both sides of its assertion, and merge_incoming_state always passes the sentinel to apply_delta, so it structurally cannot detect the sentinel becoming unsafe. The apply_delta leg is pinned separately by apply_delta_ignores_its_outer_parent_state_so_the_sentinel_is_safe, which calls apply_delta directly — once with ChatRoomStateV1::default(), once with the room's own state — over a room with non-default max_members, max_recent_messages and a real ban, the exact parent_state fields the per-field apply_deltas read.

Outbound path: why the summary is the ENTIRE attack surface

compute_update_data computes an outgoing update as state.delta(baseline, params, baseline_summary), i.e. it feeds the device's OWN last_synced_state in as if it were a receiver. Two things make that safe once the horizons are neutralised, and both were verified field by field:

1. All NINE delta impls declare _parent_state UNUSED. Checked signature by signature across configuration, bans, members, member_info, secrets, recent_messages, direct_messages, upgrade, version. This matters because compute_update_data passes the BASELINE as parent_state — a delta that read it would be consuming a stale/self quantity that outbound_summary structurally could not fix, since outbound_summary only touches the summary. Nothing does, so the summary is provably the whole surface.

2. Only two of the nine summary fields are horizon-shaped. "Horizon-shaped" means the field makes the SENDER withhold something it holds and the receiver lacks. recent_messages.horizon and direct_messages.pair_horizons are the only two; every other field is a pure have-statement (an id set, a version, a signature map), which is safe — indeed required — to feed from the sender's own baseline, because that is exactly what makes the delta "what changed since I last synced". upgrade and version are inert on this path for independent reasons: strip_upgrade_pointer forces upgrade == None outbound, and StateVersion::delta returns None unconditionally.

outbound_summary is written as an exhaustive destructure of ChatRoomStateV1Summary rather than a struct-update spread, so adding a summary field is a compile error at exactly the site that must decide keep-or-clear. That is deliberate: MembersV1 and BansV1 are deferred below as having the same defect, so the follow-up that adds MembersSummary.horizon is planned — and a spread would have compiled clean while silently reintroducing this bug on a new field. Verified by simulating that follow-up: error[E0027]: pattern does not mention field.

Reachability of the outbound bug — narrower than first stated

An earlier revision of this description said a clock-skewed device would simply never send anything. That is corrected. The UI send path applies the composed message through room_data.room_state.apply_delta before any sync tick, and MessagesV1::apply_delta sorts by (time, id) and drains from the FRONT — so on a device already AT capacity, a message sorting below the local window is dropped LOCALLY at compose time and never reaches compute_update_data.

The reachable trigger needs current BELOW cap while baseline was AT cap publishing a real horizon: either max_recent_messages was raised so back-filled older messages are retained locally but still sort below the stale horizon, or post_apply_cleanup's ban/member sweep shrank the local set while last_synced_state holds the pre-sweep snapshot. The regression test models the first, and asserts current is within its own cap so the premise stays reachable.

The invariant it protects: the #[composable] macro takes _parent_state and shadows it with a per-field self.clone(). Its own comment calls that "ugly", which is a description and not a stability promise. If a freenet-scaffold bump ever forwarded the argument, both UI ingestion paths would merge every room against a DEFAULT state — members empty, so the author-must-be-a-member retain drops EVERY message. Silent, total, local message loss. The test also asserts that the sentinel-parent MessagesV1::apply_delta drops every message, so the equality above cannot pass vacuously.

Backward compatibility

The #[serde(default)] asymmetry is inert today but hazardous. DirectMessagesSummary::pair_horizons carries #[serde(default)]; MessagesSummary::horizon does not. That asymmetry cannot bite on the cross-generation path — ChatRoomStateV1Summary decodes all its fields together, so an old-shape summary fails on recent_messages long before the DM leniency is reached. What the default DOES buy is a silent failure mode: if pair_horizons ever goes missing for any reason it decodes as empty, which disables the DM horizon filter and quietly re-opens the resend loop with no error anywhere, whereas the messages side fails loudly. Recorded deliberately: the leniency is retained for forward-compatibility with a future summary that legitimately omits the field, and the silent-degradation risk is the price.

The summary shape change is safe because it re-keys the contract. Peers on the old WASM derive a different contract key and never exchange summaries with peers on the new one; within a key every peer runs identical code fetched by that key, so there is no mixed-shape window. State encoding is unchanged, so river#292 auto-migration re-PUTs existing state forward untouched. This is the deliberate reasoning — a rollout-compatible summary shape was not needed and would have added a legacy branch for no benefit.

Not fixed here (deliberate)

MembersV1 (remove_excess_members) and BansV1 (max_user_bans) have the same defect by construction. Excluded because:

1. Their retention key depends on receiver-side state the sender cannot see — invite-chain depth against the receiver's member graph, enforcing-vs-inert against the receiver's member_info. A horizon is not expressible; they need a different design.
2. They are downstream of this fix: post_apply_cleanup prunes members by recent-message authorship, so member churn follows message churn.
3. Payloads are ~100 bytes against ~1.6 KB per message, and both caps (200 members / 10 bans) are rarely reached in the affected room.

Filed as a follow-up issue rather than stretched into this PR.

KNOWN OPEN GAP: receiver-side rejection is invisible to the sender (#490)

This PR does not fix this, and no retention horizon can. Tracked as #490; independently identified by the protocol reviewer as finding S2.

When a receiver rejects a payload in post_apply_cleanup's ban/membership sweep rather than in the cap prune, the rejection leaves no trace in its summary, so the sender can never learn it was refused. Reproduced by ban_sweep_reopening_the_horizon_still_loops_known_gap: R at 100/100 bans X, the sweep drops X's 40 messages, R falls to 60 and its horizon REGRESSES OldestRetained -> Open — so it invites MORE, not less. Two channels loop together, messages AND members, and every round is a byte-identical no-op for R.

A horizon governs only what the sender withholds; it cannot express "I refused this". Closing it needs the ban, or some rejection signal, to reach the sender — a protocol change, not a summary change.

That test deliberately asserts the broken behaviour, so the suite stays green and the defect is a CI-enforced named fact rather than a red test people learn to skip. If the gap is ever closed it fails and tells the reader to restore the terminating assertion.

KNOWN OPEN GAP: DM recipient-purges, same family (#490)

A third instance of the same mechanism, recorded on #490 rather than fixed here. A recipient purges a DM by publishing an AuthorizedRecipientPurges envelope, and apply_delta step 3 drops any held message whose token is tombstoned — but the summary publishes only purge_versions, not the tombstoned PurgeToken set (deliberately: the tokens are BLAKE3-derived so they cannot be signature-ground, and publishing the set would leak which messages were purged).

So a sender that has not seen the envelope re-offers the purged DM forever: it is absent from the receiver's signature set, and pair_horizons does not filter it because it was removed for being purged, not for being old. No horizon can cover it — a horizon is an ordering statement, and purge membership is deliberately unpublished. Bounded in practice, and a bidirectional exchange heals it (the envelope travels in advanced_purges); it is one-directional gossip that persists. Not covered by a test.

Testing

Scenario tests — common/tests/retention_loop_test.rs (14)

Asymmetric loop detectors for messages and DMs, horizon advance under displacement, back-fill for peers below capacity, idempotence, zero-cap, DM newest-N retention, and a CBOR round trip through the exact encode/decode summarize_state/get_state_delta perform. Added since the first draft:

• asymmetric_caps_terminate_in_both_directions — 50-cap and 200-cap peers of the same room, driven both ways. Differing caps are legitimate (per-room config read from parent_state) and are the case where the loop does NOT self-heal, and nothing covered them.
• ban_sweep_reopening_the_horizon_still_loops_known_gap — the Receiver-side rejection (ban sweep / membership prune) is invisible to the sender, so the exchange never terminates #490 gap above.

Property tests — common/tests/retention_proptest.rs (16, new)

Generalises the scenario tests over randomly-generated divergent windows, on a fixed-seed runner so failures reproduce:

• Delta termination — after a peer merges what a neighbour offered, the neighbour has nothing left to offer. For MessagesV1, DirectMessagesV1, and the whole ChatRoomStateV1 through merge_incoming_state plus the CBOR round trip. This is the property the bug violated.
• Retention invariant — the merged result is EXACTLY the newest min(|union|, cap) by (time, id). Deliberately an exact set equality: a "fix" that raises or removes the cap fails it, and so does a horizon that over-states.
• Commutativity, associativity, idempotence (self-merge, and re-merge producing neither state change nor traffic); the DM per-pair cap; summary byte-determinism under state-Vec reordering; max_recent_messages varied independently per peer, including 0.

Generators are biased at the failing shape — peers AT capacity with overlapping-but-different windows, ties in time broken by id, boundary entries, empty states — and the_generator_reaches_at_capacity_peers_with_divergent_windows asserts that bias holds rather than trusting it.

Mutation verification — 12 mutations, all 12 caught

#	Mutation	Caught by
M1	messages delta drops the horizon filter (the pre-fix set-difference)	merging_a_peer_leaves_it_with_nothing_further_to_offer, re_merging_the_same_peer_changes_neither_state_nor_traffic, a_zero_cap_peer_retains_nothing_and_is_offered_nothing, whole_room_state_gossip_terminates_across_the_cbor_round_trip
M2	horizon never Open (published below capacity)	a_merge_retains_exactly_the_newest_cap_entries_of_the_union, absorbing_two_peers_is_commutative, absorbing_two_peers_is_associative
M3	zero cap yields Open instead of Closed	a_zero_cap_peer_..., merging_a_peer_leaves_it_..., re_merging_the_same_peer_...
M4	horizon by index rather than min (order-dependent)	message_summary_bytes_are_independent_of_state_vec_order
M5	messages stop pruning (the WRONG "fix": raise/remove the cap)	a_merge_retains_exactly_..., a_zero_cap_peer_..., absorbing_two_peers_is_commutative, absorbing_two_peers_is_associative, the_generator_reaches_...
M6	MessagesSummary.message_ids BTreeSet -> HashSet	message_summary_bytes_..., whole_room_state_gossip_...
M7	DM delta drops the pair-horizon filter	merging_a_dm_peer_leaves_it_..., whole_room_state_gossip_...
M8	DM per-pair trim keeps the OLDEST instead of the newest	a_dm_merge_retains_exactly_..., absorbing_two_dm_peers_is_commutative, ..._is_associative, merging_a_dm_peer_..., whole_room_state_gossip_...
M9	DM summary publishes no pair horizons	merging_a_dm_peer_leaves_it_..., whole_room_state_gossip_...
M10	pair_horizons returned unsorted (HashMap order leaks out)	dm_summary_bytes_are_independent_of_state_vec_order
M11	DM per-pair cap back to first-come-wins (the pre-fix behaviour)	a_dm_merge_retains_exactly_..., absorbing_two_dm_peers_is_commutative, ..._is_associative, merging_a_dm_peer_..., whole_room_state_gossip_...
M12	DM per-pair cap removed entirely	a_dm_merge_retains_exactly_..., absorbing_two_dm_peers_is_commutative, ..._is_associative

Two results worth calling out:

• M2 is caught only by the exact-equality retention invariant and the algebraic laws — never by delta termination. An over-stating horizon suppresses more, so the delta empties sooner. Had the retention property been written as a subset check rather than exact set equality, M2 would have walked straight through.
• M10 is caught only by the new property, not by the existing direct_messages_summary_serialization_is_order_independent, which constructs the summary by hand and so never exercises pair_horizons()'s internal HashMap.

Mutation testing changed the tests, twice more than the first draft recorded. Two originally-written bidirectional merge fixpoint tests turned out to be unable to fail and were rewritten as one-directional loop detectors. Then, on the property suite: a uniform-subset generator reached the 100-message DM cap in 5 of 512 cases, making every DM property near-decorative — fixed with a capacity-biased generator, with the bias now asserted. And dm_summary_bytes_are_independent_of_state_vec_order originally loaded one pair, but pair_horizons only emits an entry per at-capacity pair and a one-element Vec has no order to get wrong; it now loads both pairs, which is the only reason M10 is caught.

CI coverage gap — closed UPSTREAM, not here

An earlier revision of this description claimed this PR closed a CI gap. That claim is corrected: origin/main already closed it.

The finding was real when made — build.yml enumerated river-core test targets one at a time, cargo test -p river-core --lib does not build integration targets, and the enumeration covered only 7 of 14, so convergence_tests, direct_messages_test, deputy_ban_test, private_room_test, import_merge_test, memberid_test, stdlib_compat_test and this PR's own retention_loop_test never ran. But #481 (9a988954) independently added cargo test -p river-core --tests, and this branch's merge-base predated it.

After rebasing, build.yml here is byte-identical to main — the rebase would otherwise have left a duplicate --tests step running the slowest job twice. The retention suite is CI-gated, just not by this PR.

Migration

The room contract re-keys. The chat delegate deliberately does NOT.

An earlier revision of this branch re-keyed both, registering a V29 entry in each registry. The delegate half has been reverted, because that re-key was pure collateral:

• Summary, merge, summarize and apply_delta appear in delegate source only inside comments — the delegate never summarises or merges room state.
• The one contract-state type it does use, ChatRoomStateV1Delta, is unchanged: both type Delta declarations are identical to origin/main, and DirectMessagesDelta is byte-identical. This PR changed the SUMMARY types, not the DELTA types.
• The delegate WASM had moved for codegen reasons alone, with no behavioural difference.

A V29 delegate entry would nonetheless push every user through a legacy-delegate migration — the single highest data-loss-risk step in a River release (the March 2026 incident in wasm-safety.md; and old delegate WASM built against stdlib <0.1.34 cannot execute on the current runtime). Taking that risk for zero benefit is a bad trade, so ui/public/contracts/chat_delegate.wasm is restored to origin/main's bytes, the V29 delegate entry is dropped, and the legacy_set_fingerprint pin reverts to b2824be852437587. The delegate key is unchanged from main, so nobody migrates.

Both --ci origin/main HEAD gates confirm the split:

check-migration.sh            → "Committed WASM unchanged — no migration needed."
check-room-contract-migration → "Old hash found in common/legacy_room_contracts.toml"

Read that green delegate gate accurately — it does not validate this revert's premise. scripts/check-migration.sh compares COMMITTED bytes at base vs head and never rebuilds anything. So it confirms the committed delegate is unchanged from main, which is the property users care about (no re-key, no migration), but it is structurally incapable of noticing that the committed delegate WASM is no longer this branch's build product. That gap is real and deliberate: a fresh --locked build of the delegate on this branch yields f3848929…, not the committed 2f8c5f1d…. The justification for shipping main's bytes is the source-level argument above (the delegate never summarises or merges, and ChatRoomStateV1Delta is unchanged), not the green check.

Consequence for whoever publishes: scripts/sync-wasm.sh copies BOTH WASMs unconditionally. This branch ran sync-wasm for the room contract and then hand-reverted the delegate half, so re-running cargo make sync-wasm here would silently re-key the delegate again with no V29 delegate entry present. The ordinary publish path is safe (include_bytes! reads the committed file; build-chat-delegate writes only to target/), and a committed re-copy would trip the gate — but do not run sync-wasm on this branch.

Final committed hashes (these are the bytes that will publish):

artifact	BLAKE3	re-keys?
room_contract.wasm	f8cca7600a63dac16de1974e08211e3eb6e530713a8cfe78caed3a66372a3e50	YES — V29 registered
chat_delegate.wasm	2f8c5f1d5c517e57208538fb2a7ec819e882eafa29bc43047eb6c025b37eba8e	NO — identical to main

No V30 entry. A migration entry records the hash you migrate FROM. V29 pins origin/main's hashes (room 5ae5930a..., delegate 2f8c5f1d...) — the generation live rooms actually sit on — so the new hash moving cannot invalidate it. The intermediate WASM this branch carried before the version bump (2a782ca8... / c281c2c7...) was never published, so it is replaced rather than registered; registering an unpublished intermediate would pollute the registry with a generation no room ever used.

verify() is untouched, asserted byte-identical to origin/main in both message.rs (29 lines) and direct_messages.rs (115 lines). This is load-bearing: the forward-migration PUT is gated on validate_state = verify alone, so tightening it would make existing state REJECTED and lose rooms.

river-core 0.1.18 (version bump)

common/ changed but [workspace.package] version was still 0.1.17, which is already on crates.io. cli/Cargo.toml declared river-core = { version = "0.1.17", path = "../common" }, so a published riverctl 0.2.4 would resolve river-core from crates.io — the OLD summary shape, no RetentionHorizon, no pair_horizons — while embedding the NEW room-contract WASM.

Independently of any runtime failure, publishing a crate whose resolved dependency differs from the source it was built against is wrong, so the bump is hygiene rather than a bet on a failure mode. That a stale river-core would actually fail at runtime is reasoned, not proven: the two summary types gained non-Option fields on the decode path, and the v0.2.11 incident is the precedent. An end-to-end demonstration was deliberately skipped as it could not change the decision.

Measured, not assumed: building the key-defining WASMs with --locked at 0.1.17 reproduced the committed bytes exactly, and at 0.1.18 moved both (river-core's version feeds -C metadata for both crates). cargo make sync-wasm then reproduced the 0.1.18 hashes a third time.

riverctl's river-core requirement is pinned exactly

cli/Cargo.toml now reads river-core = { version = "=0.1.18", ... }, not "0.1.18" (which is ^0.1.18). cargo install re-resolves dependencies by default — it does not use the packaged lockfile without --locked — so under a caret range a fresh cargo install riverctl@0.2.4 performed after river-core 0.1.19 ships would link 0.1.19 against the 0.1.18-era bundled WASM. That is the same v0.2.11-class skew this version bump exists to prevent, merely deferred by one release.

Known gap in the check-wasm-sync gate

check-wasm-sync compares cli/Cargo.toml's version against crates.io and nothing else. A version bump alone fully satisfies it while the underlying river-core requirement stays stale — which is exactly the case that would have shipped this break. A follow-up should make it also compare the river-core requirement against [workspace.package] version.

No room recreation, gkapi change, secret rotation, or invite reissue — all key off the unchanged owner VK. Clients auto-migrate on refresh (river#292).

Do not publish from this branch

Publishing is sequenced separately by the River master agent; this re-keys the live room.

[AI-assisted - Claude]