## Why
Fixes#6886. In the channel timeline an edited message shows its newest
body, but opening its thread panel showed the stale pre-edit body until
the async thread-aux backfill landed (and permanently if it raced or
missed).
## Root cause
`desktop/src/features/messages/lib/independentThreadPanel.ts` built
`events = [head, ...replyEvents]`, discarding the head's aux overlay
events (edits `kind:40003`, deletions, reactions) already present in the
channel window. `formatTimelineMessages` only applies an edit when the
edit event sits in the same array as its target, so the thread head
relied solely on `withThreadAux` to re-supply it.
## What
- Carry the head's non-content aux events (via
`!isTimelineContentEvent`) from the channel window into the thread
head's event array, deduped against `replyEvents` by id.
- Thread head is now byte-identical to the main timeline the instant the
thread opens, independent of the async aux fetch.
- Restricted to non-content kinds so reply content rows never leak in.
## Tests
- Unit regression `independentThreadPanel.test.mjs` (6 cases): red
pre-fix (`"two PRs"`), green post-fix (`"these PRs"`).
- e2e `thread-head-stale-edit.spec.ts`: delays thread-replies aux to
force the channel-window-vs-thread-aux divergence, then opens the thread
via the reply button and asserts the panel head shows the edited body.
Verified red pre-fix (stale `message-thread-panel` head), green
post-fix.
- Full desktop unit suite: **5562 pass / 0 fail**. `biome` + `tsc
--noEmit` clean.
Origin: Buzz channel `fix-reply-thread-old-view-bug`
(#464b982f-fc05-42c8-918f-409e1f05a1df).
---------
Signed-off-by: Leo <5faf251baee50ee6bcde338aef6acdd70bb3e60115664c2cd490d94a55dfc488@buzz.block.builderlab.xyz>
Co-authored-by: Leo <5faf251baee50ee6bcde338aef6acdd70bb3e60115664c2cd490d94a55dfc488@buzz.block.builderlab.xyz>
