fn queue_target_layout_insert(
store: &Store,
target_tab_id: &str,
block_id: &str,
) -> Result<(), Box<dyn Error>>Expand description
Floating-pane re-dock — enqueue an “insert” action on the TARGET
tab’s LayoutState.pendingbackendactions so the target window’s
frontend adds a new leaf for the redocked block through its
LayoutTreeActionType.InsertNode reducer pathway.
Why this and not direct rootnode/leaforder writes? The frontend’s
LayoutModel maintains its own in-memory tree state and doesn’t
auto-sync from external LayoutState WaveObj updates — so a
backend store.update to the rootnode lands in the WOS cache
but the LayoutModel never picks it up, and the next frontend-
initiated object.UpdateObject overwrites the backend version
with the LayoutModel’s stale tree. The pending-actions queue
(onBackendUpdate in layoutPersistence.ts:50) is the canonical
channel for “backend wants the frontend to mutate its layout
tree”. Source-delete on tear-off uses the same channel via
queue_source_layout_delete.