fix(dm): share-invite-via-DM picker no longer hangs at "generating" (Bug #2)

[sanity]

Problem

Ivvor on Matrix (2026-05-17): "Share Invite" option to member doesn't work. It allows the target room to be selected but then goes to "Generating" and the browser tab locks up, eventually requiring it to be closed. Tested on both members with and without an existing DM channel active. Same failure on Chrome and Firefox.

Root cause: DmThreadModalBody's use_effect that drains DM_DRAFT deferred the signal clear via crate::util::defer(...). The effect subscribes to DM_DRAFT AND (via draft.read()) to the local draft signal, then calls draft.set(merged) inside the effect. Because Dioxus re-renders happen on the next microtask but defer() schedules via setTimeout(0) (a macrotask), the re-fired effect saw the still-Some DM_DRAFT, appended body to the merged draft again, and looped forever — burning CPU until the user closed the tab.

This matches Ivvor's repro exactly: pick a target room → picker's deferred state-flip lands first, opening the DM thread modal → that modal mounts → first use_effect run starts the infinite loop → tab hangs at the "Generating…" state shown by the still-open picker behind it.

The deferred-clear pattern was already documented as forbidden in AGENTS.md "Dioxus WASM Signal Safety Rules" → "Never defer signal clears in use_effect". The same rule was called out explicitly in app.rs:124 for the invite-click interceptor. We just forgot to apply it here.

Approach

Align DM_DRAFT with the rule:

1. Clear DM_DRAFT synchronously BEFORE draft.set() — kills the re-fire loop at its source. Same shape as the invite-click interceptor in app.rs.
2. Read draft via .peek() (not .read()) so the effect never subscribes to its own writes — defence in depth.
3. Extract the merge logic to a pure helper merge_invite_into_draft so the regression can be pinned without touching Dioxus signal subscription wiring.

Considered alternatives:

• Removing the use_effect entirely and draining in an onclick: would lose the auto-open-on-mount behaviour from the picker; the picker doesn't know whether the thread modal is already open vs. about-to-mount.
• Removing only .peek() change, keeping defer(): insufficient — the effect still subscribes to DM_DRAFT, and the defer-clear still loses the synchronous-clear race against Dioxus's microtask re-render.

The fix is the minimal change that satisfies the project rule.

Testing

New unit tests in dm_thread_modal::tests:

• merge_invite_into_draft_replaces_empty — empty draft → body becomes draft
• merge_invite_into_draft_replaces_whitespace_only — whitespace-only also counts as empty
• merge_invite_into_draft_appends_after_user_text — user text preserved, body appended after blank line
• merge_invite_into_draft_trims_trailing_whitespace_before_appending — no double-newlines from trailing whitespace
• merge_invite_into_draft_is_not_self_stable_without_external_clear — regression pin for bug(dm): same-second inbound DM stays hidden after hide cutoff #267: asserts the merge GROWS on re-application, documenting that the synchronous DM_DRAFT clear is the only thing preventing the hang.

Full workspace tests pass (cargo make test): 129 UI tests + 24 chat-delegate tests + room-contract / web-container / common tests.

cargo check -p river-ui --target wasm32-unknown-unknown --features no-sync clean.

Clippy: no new warnings (5 pre-existing warnings in unrelated files: app.rs unused import, room_synchronizer.rs complex-type, conversation.rs clone-on-copy — all on main).

Test plan

• Unit tests pin merge math
• Workspace tests pass
• Manual repro pre-fix on main: pick a target room → tab hangs (parent agent's playwright-MCP verification, see report)
• Manual verification post-fix: pick a target room → DM thread modal opens with invite URL pre-filled, no hang

[AI-assisted - Claude]