class WindowScope

The per-window half of LavaUI's framework state.

ViewInvalidation, FocusManager, NodeVisibility and the caret blink were written as process-wide statics under an explicit single-window assumption. With two windows in one process each of them is a bug: window A consuming the invalidation level swallows window B's redraw, a key event delivered to B reaches the field focused in A, and A's emitTree clears the visibility set that B's animations are gated on.

The fix keeps every one of those APIs exactly where it was — forty-odd call sites across widgets say ViewInvalidation.markNeedsRedraw() with no window in scope, and threading one through all of them would be both invasive and wrong, since a widget genuinely does not know which window it is in. Instead the storage moves here, and the statics resolve to a scope:

• Ambient. The frame loop marks a window current around everything it does for that window — input, body, layout, emit. A widget invalidating from a click handler or a body therefore lands in the right window without ever naming it.
• By node. markBodyDirty(node) cannot use the ambient scope: an @Observable model mutated by a handler in window A can be observed by a node in window B, and B is the one that has to recompute. CompositeNode captures its scope at mount, when the ambient one is correct by construction, and routes there for the rest of its life.
• Broadcast. Outside any window phase — MainQueue results, deferred FrameTasks — there is no answer to "which window", so a coarse invalidation goes to all of them. Wasteful in the case where only one window cared, but never wrong, which is the correct trade for the path that runs once per worker result rather than once per frame.

Single-window behaviour is unchanged: everything resolves to .main.

What deliberately stays global is anything keyed by NodeID, because those ids are unique process-wide and so cannot collide between windows — ScrollRouter, DropRouter, PointerCapture, AnimationDriver's registry. So is anything the loop owns rather than a window: FrameScheduler (one loop, one sleep, earliest wake wins), FrameTasks, MainQueue. And so are the resource caches — FontStore, ImageStore, Theme — which is the whole reason a second window is cheap.

Not thread-safe, and not meant to be: it is read and written by the frame loop only. That is exactly what MainQueue exists to preserve.