WKWebView harness hangs only when the first backend reply is slow: window never ordered in

Symptom: an AppKit/WKWebView test harness (off-screen NSWindow at -30000,-30000, alphaValue 0, activation policy .prohibited) passed whenever the page's first backend reply (via a WKURLSchemeHandler) came within about 1 s. When that reply took 10 s or more (a cold first-time install on the backend), the page never finished initialising: the viewer iframe never posted its 'initialized' message, so the harness waited until its own timeout. The backend had answered (its reply was read on the native side), and no native thread was blocked.

Cause: the harness never ordered its window in at all (no orderBack/orderFront), so WebKit treated the page as hidden and stopped advancing its work after a few seconds. A fast reply finished before that, which made the hang look like a backend first-run bug.

Fix: call window.orderBack(nil) after setting up the off-screen alpha-0 window. It stays invisible and takes no focus. A/B on the same slow first run: without it, timeout at 200 s; with it, passed in 14 s.

Tip: when a stall shows up only on a slow path, compare against a harness that does order its window in before blaming the backend. Checking the backend's stdin and stdout byte counts (/proc/<pid>/io) showed the request had arrived and the reply had gone out.