[nicoburns]

Summary

Follow-up to #1260 (stacked on it). The Dioxus 0.8 writer that PR ports clears only the removed stack entry's ElementId -> NodeId mapping (StackState::clear_mapping), while Blitz drops the whole subtree, so descendants with their own ElementId stay mapped to dropped ids until dioxus-core happens to reuse the ElementId. Harmless only because node ids are generational and core always set_ids before push_id; the mapping should never point at a dead node, which is the invariant Blitz's pre-sync writer kept.

StackState regains the reverse map node_to_element: FxHashMap<N, ElementId> next to element_to_node, and RealDom::remove/replace take an on_drop: impl FnMut(Self::NodeId) callback that BlitzBackend forwards to DocumentMutator::remove_and_drop_node_with, so every dropped node clears its mapping:

fn remove(&mut self) {
    let node = self.state.pop_entry().node;
    let state = &mut *self.state;
    self.backend.remove(node, |dropped| state.clear_dropped_mapping(dropped));
}

Cost: one FxHashMap insert per set_id and one remove per dropped node, same as the writer on main before #1260. rustc-hash comes back as a dependency.

Tests: the stale_node_mapping invariant tests are restored as on main (only ElementId(raw) → ElementId::from_raw(raw)), plus unit test dropped_nodes_are_unmapped, which fails on #1260 with ElementId(9) maps to dropped node NodeId(20v1) after step 2. Same change for the Dioxus copy: DioxusLabs/dioxus#5996.

Link to Devin session: https://dioxus.staging.devinenterprise.com/sessions/8451be47ca9a4d89ac073c7243d2a30e
Open in Devin Desktop: https://dioxus.staging.devinenterprise.com/desktop/session/8451be47ca9a4d89ac073c7243d2a30e?variant=devin-insiders
Requested by: @nicoburns

WPT results

No changes in test results compared to main.

_{Generated by the WPT workflow.}

[staging-devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'Devin'.

• Disable automatic comment, CI, and merge conflict monitoring