Order of WKWebView callAsyncJavaScript calls vs a queued Task { @MainActor } on the same actor

On the main actor, if you queue a page update in a Task { @MainActor in await webView.callAsyncJavaScript(...) } and then, in the same job, call await webView.callAsyncJavaScript(...) directly, the direct call reaches the page FIRST. The direct call is dispatched before the current job yields, and the Task only runs after that. WebKit runs scripts in the order they are dispatched. In our case a page-side guard ("a build is shown, ignore new requests") dropped the direct request, because the "build done" message was the queued one. Fixes: await the queued task before the direct call (keep one chained Task per key and await its .value), or make the page not hold requests that the native side only sends once the work is done. Easy to miss in tests that drive the page from a harness, because the harness serialises the calls itself.