fix(desktop): hydrate reactions for Inbox context messages

[wesbillman]

Problem

Adding a reaction from the Inbox looked broken: the emoji burst played and the pill appeared, then vanished ~1s later. Nothing seemed stored.

The kind:7 event was stored on the relay all along — the write path is identical to the channel view. The failure was on the read path: reactions carry only an #e reference (no channel tag), so the channel-window query never returns them for thread replies, and the Inbox — unlike the channel view — had no reaction hydration step. Its post-toggle refetch came back reaction-less and clobbered the optimistic pill.

Fix

• useInboxThreadContext now fetches kind:7 events by #e reference for the rendered context messages (same buildChannelReactionAuxFilter path the channel view uses) and exposes refreshReactions.
• HomeView merges those hydrated reaction events into the reaction pass and refreshes them after a toggle, so the refetch confirms the pill instead of clobbering it.

Test

New smoke e2e (inbox-reactions.spec.ts) reproduces the exact reported shape — a thread-reply mention reacted to from the Inbox detail pane — and asserts the pill survives both the post-toggle refetch and a full re-select (all optimistic state dropped). Supporting mock-bridge changes: #e-keyed aux filters are served across channel stores like the real relay, and emitted mock messages can carry a 64-hex id (required to be a valid reaction target).

Verified: typecheck, biome check, 1953 unit tests, full smoke suite (391 passed; the 2 failures — channels scroll-intro, custom-emoji edit — fail identically on the parent commit without this change).

[wesbillman]

Screenshots (from the new e2e, fix applied)

Reaction added from the Inbox detail pane — pill persists after the post-toggle refetch (this is the moment it used to vanish):

Item re-selected, all optimistic state dropped — pill renders purely from fetched relay data:

[wesbillman]

Reviewed on behalf of Wes. LGTM with two non-blocking notes.

Verified:

• Fix reuses the channel view's exact hydration primitives (fetchAuxEventsByReference + buildChannelReactionAuxFilter, the #e-keyed/no-#h filter) — the Inbox was the only reaction consumer without this step, so the diagnosis and the fix location line up.
• Remove path: kind:5 soft-deletes the reaction server-side, so the awaited refreshReactions() → refetch() sequence correctly drops the pill; no resurrection from stale cache.
• Duplicate merge of channelMessages + hydrated reactionEvents is safe: formatTimelineMessages dedupes presence on targetId:actor:emoji (covered by an existing unit test).
• Merge-base is current main tip.
• CI red is only scroll-history.spec.ts:1546 on Smoke shard 4 — the identical test failed on a plain-main run today (run 28881441134). Pre-existing flake; shard re-run should clear it.

Non-blocking:

1. fetchReactions's bare catch { return null } — a console.error (as renderScopedReactions.ts does) would make the next read-path failure findable; this bug was born from a swallowed error.
2. The e2e re-select dance is a little magical; selecting a genuinely different item (or a comment) would make the "purely from relay data" assertion more robust.

Separate follow-up (pre-existing on main, not this PR): canReact still allows reacting on kind 45001/45003 summary items while canReply excludes them.