Function handle_update_window_meta 

pub(super) fn handle_update_window_meta(
    state: &mut State,
    window_id: String,
    meta_patch: Value,
) -> Vec<Event>

Phase E.5.x (issue #855) — apply a meta-patch to a window. Pass- through to Event::WindowMetaUpdated; the persist subscriber performs the merge against mstore. Same shape as handle_update_workspace_meta — reducer state does NOT track window meta, the migration property is “every mutation goes through the reducer’s broadcast bus” so the MuxObjUpdate bridge can fan out to the frontend.

Validates the window exists, matching its three sibling meta arms (handle_update_workspace_meta / handle_update_tab_meta / handle_update_block_meta) — this arm used to be the sole outlier with no guard, which made POST /api/v1/window/name report success for well-formed-but-nonexistent window ids (the persist subscriber’s apply_window_meta_updated silently no-ops on a mstore miss, so nothing downstream caught it either). The guard is safe because state.windows reliably mirrors real windows: every runtime creation goes through handle_create_window, and persist::bootstrap_state_from_mstore hydrates pre-existing windows (including the wcore-seeded first-launch window, created before hydration runs) at startup. The old “wcore-direct paths won’t appear here” caveat this comment used to carry predates that hydration. SPEC_WINDOW_NAME_API_HARDENING_2026_08_08.md §3.1.