The swap left the shared chrome overlay with no way to appear. Making it visible was `applyOverlayFollow`'s job alone — the overlay window is created hidden and only ever appeared through the reducer's non-activating show — and that arm became a no-op. `AttachOverlay` carried neither a show intent nor a frame, so after the swap no window had chrome, for the whole session. Three more consequences rode along. A retarget never reframed, because the follow rule fired only on a host bounds diff and an attach does not move the host. When it did fire it wrote the raw host rect rather than the expanded overlay frame, losing the gutter and trigger-zone band. And a host entering fullscreen no longer hid the overlay; the bounds diff re-bounded it over the fullscreen window instead. The overlay's visibility and frame are now stored facts that `evolve` writes and `react` diffs, rather than anything derived from the attach event's identity — `react` is a projection of the transition and may not branch on which event caused it. The frame diff is emitted before the visibility loop so bounds always precede a show, and the op token is stamped only on a genuine reveal. The frame stays data computed by the caller. Expanding a host rect into the overlay frame needs a work-area read, which is platform data the kernel cannot obtain under its zero-value-import rule; recomputing the gutter math inside the kernel would duplicate the helper without removing that dependency. The attach target now admits quick-view. Peeks and slides open as page hosts specifically to get the shared address bar and have no navbar of their own, so excluding them painted chrome around whichever page sat behind them, or left them with no address bar at all. The docblock argued the exclusion kept the overlay off a peek while the page beneath went chrome-less; that reasoning inverts for a frontmost peek, which is the window being worked in.