Function queue_target_layout_insert 

pub(crate) async fn queue_target_layout_insert(
    state: &AppState,
    target_tab_id: &str,
    block_id: &str,
) -> Result<(), String>

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 MuxObj updates — so a backend store.update to the rootnode lands in the MOS 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) 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.

SPEC_864 Phase 4 — appends through the reducer (queue_layout_actions_via_reducer), not store.update.