feat: hide stale DM threads from left rail (#261)

[sanity]

Problem

After #244 / #258, every DM thread the local user is party to shows in the
left-rail "Direct Messages" section forever. A one-off back-and-forth from
six months ago clutters the rail with no way to dismiss it. The issue
explicitly differentiates this from "Purge thread" / riverctl dm purge,
which is destructive across the network — what's needed is a local-only
view filter.

Approach

• Storage piggybacks OutboundDmStore (feat: persist outbound DM plaintext in the chat delegate #256's delegate blob). A new
  hidden_threads: Vec<HiddenDmThreadEntry> field is added to that struct
  with #[serde(default)], so pre-feat: hide stale DM threads from the left rail (local-only) #261 wire bytes still decode into an
  empty list (pinned by outbound_dm_store_decodes_legacy_{json,cbor}_…
  tests). Vec-of-struct rather than HashMap per the "non-string map
  keys in JSON-serialized API types" bug-prevention pattern.

• Filter is the pure helper
  river_core::chat_delegate::is_thread_hidden(hidden, room, peer, max_ts)
  using strict <= so the message whose timestamp seeded hidden_at_ts
  doesn't itself revive the thread, but any strictly newer message does.
  The UI wraps it in is_thread_hidden_for for the in-memory
  HashMap<(VerifyingKey, MemberId), HiddenDmThreadEntry>. The rail's
  build_view runs the filter alongside the existing per-peer
  accumulation.

• Outbound send to a hidden peer revives the thread automatically:
  the new message's unix_now() timestamp is strictly later than the
  recorded hidden_at_ts, so the filter returns false on the next
  render. No special-case code needed.

• "Hide thread" button in the DM thread modal header — separate from
  the existing ✕ close button (smaller, hover-yellow vs. hover-text), with
  the tooltip the issue called for: "Hide this conversation from your
  sidebar. It will come back when either of you sends a new message."
  Clicking it captures the current latest-message timestamp (or
  unix_now() for empty threads) and closes the modal.

• Multi-device: hides ride the same delegate blob as outbound DMs, so
  a hide on device A is visible on device B on the next reload. No second
  storage key, no second legacy-migration probe.

• Conflict resolution on hydrate keeps the entry with the larger
  hidden_at_ts — the most recent hide intent wins. Matches the same
  rule used for OutboundDmEntry.timestamp in the existing cache.

• unhide_dm_thread is implemented (and tested) but not exposed in
  v1 — the issue says a "Hidden conversations" submenu is optional and
  not required.

Delegate WASM migration

river-core::chat_delegate changed (new types added), so the delegate
WASM hash changed too. V19 entry added to legacy_delegates.toml and
verified via cargo make check-migration plus cargo test -p river-core --test migration_test. Room contract WASM also rebuilt as a side effect
(its river-core dep is the same), but room-contract migration is
automatic via the existing regenerate_contract_key() path.

Testing

13 unit tests in river-core::chat_delegate:

• outbound_dm_store_with_hidden_threads_{json,cbor}_round_trips — pins
  the new wire shape
• outbound_dm_store_decodes_legacy_{json,cbor}_without_hidden_threads —
  pins backwards compat with pre-feat: hide stale DM threads from the left rail (local-only) #261 blobs
• is_thread_hidden_returns_false_for_empty_list — fast-path
• is_thread_hidden_equal_timestamp_stays_hidden — strict <= boundary
• is_thread_hidden_strictly_later_message_revives — revival semantics
• is_thread_hidden_is_scoped_per_room and …_per_peer — lookup tuple
• is_thread_hidden_zero_max_zero_hidden_stays_hidden — empty-thread edge

Plus the existing outbound_dm_store_{json,cbor}_round_trips /
empty_outbound_dm_store_json_round_trips updated to match the new
struct shape — they still verify the original entries round-trip.

• cargo test -p river-core --lib — 154 passed
• cargo make test (full workspace) — all green
• cargo make check-migration — V19 entry validated against the
  pre-change WASM hash
• cargo check -p river-ui --target wasm32-unknown-unknown --features no-sync
• cargo fmt, cargo clippy -p river-core clean

Manual end-to-end Playwright not run for this PR — the filter behaviour
is covered by the pure-helper unit tests, and the UI plumbing (signal
hydrate / save / button wire-up) is structurally identical to #256's
OUTBOUND_DMS path that already shipped.

Closes #261

[AI-assisted - Claude]

🤖 Generated with Claude Code

[sanity]

Codex review (round 1) findings + responses

P1 (FIXED in a60814e): "Same-second or clock-skewed DMs do not revive hidden threads." Both hide_dm_thread's hidden_at_ts and the outbound DM's message.timestamp come from unix_now() (1-second resolution), so hide-then-immediately-send can leave the thread stuck-hidden. Fixed by explicitly calling unhide_dm_thread from the ApplyOutcome::Applied arm — idempotent no-op when no entry exists. Removes the dependency on timestamp comparison for the outbound-revives case.

Inbound revival on clock-skewed sender timestamps remains filter-only. Fixing that requires a ROOMS-subscribed effect diffing prior-vs-current direct_messages.messages for new inbound entries, which is more invasive than this PR warrants for the same-second corner case. Filed as a deferred follow-up (low severity: skewed-clock peers are already eventually-revived when ANY message with a non-skewed timestamp arrives).

P2 (ACKNOWLEDGED, deferred): "A local UI/view-state feature unnecessarily changes the room contract WASM." Correct observation. The river-core crate is depended on by both the room contract AND the chat delegate, so any change to common/src/chat_delegate.rs rebuilds both WASMs. The room-contract migration is fully automatic via regenerate_contract_key() (see AGENTS.md "Contract Upgrade") — it's not a user-impacting migration, just a churn of the contract key on next load. Splitting river-core::chat_delegate into a separate crate that only the delegate (and UI/CLI) depends on would eliminate the churn, but that's a structural refactor not in scope for this PR. Filed as a follow-up candidate.

Re-running Codex on commit a60814e to verify the P1 fix.

[AI-assisted - Claude]

[sanity]

Codex round-2 findings + response

P3 (FIXED in 3c41af4): "Late hydration can still resurrect a just-unhidden thread." Real race: hydrate_hidden_dm_threads running AFTER unhide_dm_thread re-inserts the just-removed entry from a delegate response that was in-flight at the moment of unhide. The strict <= filter then re-hides the thread when the outbound DM's unix_now() landed in the same second as the original hide.

Fix: a session-scoped RECENTLY_UNHIDDEN: HashSet<(VerifyingKey, MemberId)> tombstone. unhide_dm_thread inserts into the set BEFORE its deferred signal write; hydrate_hidden_dm_threads consults the set and drops any matching incoming entry. The hot-path was refactored to go through a new pure helper resolve_hidden_thread_hydration so the suppression logic is unit-testable.

Also: unhide_dm_thread now queues an unconditional delegate save (rather than only-when-something-was-actually-removed). Without this, the on-disk hidden_threads from a prior session would resurrect on next reload — the tombstone is session-only by design.

6 new unit tests pin: insert-into-empty, keep-fresher-in-memory, take-fresher-incoming, suppress-recently-unhidden, suppression-scoped-per-peer, suppression-scoped-per-room.

Re-running Codex on 3c41af4 to verify the P3 fix.

[AI-assisted - Claude]

[sanity]

Codex round-3 Low finding response

Codex round-3 (on 3c41af4) confirmed the P3 fix is correct and noted one Low:

Low (FIXED in 18cc4d1): resolve_hidden_thread_hydration compared each incoming entry only against the pre-existing current map, not against earlier entries in the same incoming Vec. A malformed legacy blob containing the same (room, peer) twice in newer-then-older order would let the older cutoff overwrite the newer one when the caller does the final HashMap::insert loop. Normal UI writes go through a HashMap snapshot so this can't arise on our write path; the fix is defensive against any other writer or corrupt-data scenario.

Fix: fold incoming entries through a temporary HashMap keyed by (room_vk, peer), keeping whichever cutoff is largest. The "largest hidden_at_ts wins" documented invariant is now actually upheld.

Two new unit tests pin the dedup behaviour: newer-then-older and reverse-with-tie. Total chat_delegate tests in river-ui now 13.

Re-running Codex on 18cc4d1 to confirm; then planning to squash-merge once that and CI come back clean.

[AI-assisted - Claude]

[sanity]

Filed #266 to track the deferred Hidden conversations sub-menu — the v1 un-hide UX that the original issue marked as optional. PR #265 keeps the implicit revive paths (newer inbound message / outbound send) as the v1 mechanism; the explicit submenu is now tracked separately.

[AI-assisted - Claude]

[sanity]

Re: Codex P2 finding (same-second inbound DM hide race)

Codex flagged that the strict <= in is_thread_hidden means an inbound DM landing in the same Unix second as the hide click stays suppressed until a later-second DM arrives. This is a real but narrow race in the underlying feature design — the outbound path has the explicit unhide_dm_thread workaround (the P1 fix Codex flagged in round 1), but the inbound path has no equivalent.

I'm deferring this to issue #267 rather than fixing in #265 because:

1. The behaviour is pre-existing in the feature design as merged in the previous reviews — not introduced by my new commit (which is purely tests + a doc comment + a pure-helper refactor).
2. The most-defensible fix is mirroring the outbound path in the room-state apply hook — that's a real behaviour change that wants its own focused review.
3. The race is narrow: only triggers for messages landing in the exact same Unix second as the Hide click, and recoverable via any later-second DM or directly opening the thread.

PR #265's job at this point is to land the test coverage for the BLOCKING gaps the testing reviewer flagged. #267 will track the symmetric inbound-revive fix.

[AI-assisted - Claude]