fix(tabs): keep the transcript when a tab drag reparents its view

[Adam-Dalloul]

Dragging a conversation tab empties its message list. The composer, the header and the tab title all stay right, and the messages only come back after the tab is closed and reopened.

A drag that carries the tab into another group reparents its view, and that unmount removed the conversation's runtime session even though the connection is deliberately carried across it. The remounted view then re-registers its live-message sink on the connection it kept, which recreates the session with live data and no detail, and fetchDetail skips a session that already has live data, so nothing refetches and the list stays empty.

The unmount now asks isReparentUnmount first, the same classifier the connection teardown already uses, and leaves the session alone when the tab is only changing groups.

reorderTabs is fixed alongside it. Reorder.Group emits the order of the items it has measured since its own last render, filtered by reference against its current values, so mid-drag it can hand back a list that is short, repeats an id, or carries a tab object from an earlier derive. The unsplit strip adopted that list as the whole tab set, so a drag could close whichever tab was missing from it, leave activeTabId pointing at nothing, or write a stale copy of a tab back over the current one (a draft that bound to a conversation mid-drag went back to being an unbound draft). It now resolves every entry to the live tab by id and refuses anything that is not a permutation, which is what its split-group sibling already did. Both go through one helper.

Six new tests. Three of the four reorder tests fail on main, and so does the reparent wiring; the remaining two pin the behaviour that must not move, including why an emptied list cannot refill itself.