setStacking asks for relative z order and nothing else. Off darwin the primitives that realize it — moveTop() for a stacked window, setAlwaysOnTop(true, 'floating') for a pinned one — activate the window as a side effect, and that focus was being reported as OS_FOCUS_GAINED. A focus report is a genuine key diff, a key diff emits RaiseWindow, and RaiseWindow is realized as an activating show that reorders again, so the reorder re-ran the whole stacking band replay and the cycle sustained itself at roughly 2ms a lap with no external input. This is the principle raiseWindow already states and honors by echoing WINDOW_SHOWN rather than OS_FOCUS_GAINED: a machine-initiated operation must not feed its own side effect back in as fresh OS evidence. setStacking now arms pendingStackingFocus before its native call, and the window 'focus' listener consumes that arming and declines to emit. A machine-armed focus still reports, because a focus-family command genuinely asked for that one; the arming is dropped on blur, on close, and whenever armSelfCausedFocus supersedes it, so a never-consumed arming cannot swallow a later real focus. Scoped to platforms whose z-raise primitive activates. On macOS moveTop() reorders without taking key, so STACKING_TAKES_FOCUS is false and the suppression is inert there — unverified, since only the active branch has been exercised. Measured on Linux. A six-round activation reproduction went from rounds [true, true, false, false, false, false] to all six true; native focus reports over that run fell from 227 to 15 and emitted effects from 1230 to 142. The seven Hybrid Chrome Overlay side-panel and notes/widgets specs went from 5 passed / 2 failed to 7 passed / 0 failed on two consecutive runs, and the six window-operation patterns from 41-42 passed / 20-21 failed to 53 passed / 9 failed, wall clock 92.5s against roughly eight minutes. check-r2-window-ops holds at 15 entries / 23 calls, check-platform-leak at 0 leaks.