jsaddle-wkwebview: invalidate under wkWebViewBatchLock - #173

Problem

jsaddleWebViewInvalidate (added in #171) closes a context's gate after waiting only for an in-flight send — the aliveVar section around evaluateJavaScript. But runJavaScriptWithSerializer holds the shared wkWebViewBatchLock from a batch's send until its reply arrives (sendBatch >> takeResult).

So if a context is invalidated after one of its batches has been sent but before the reply comes back, that reply is lost: the inbound gate drops it and the handler is detached. The batch thread then waits in takeResult forever while still holding the lock, and every other webview in the process hangs on its next round trip. It only recovers if/when the GC notices the orphaned wait.

This shows up as soon as a host invalidates one window's context while others keep running. In leksah, closing one window at a time froze the remaining windows for 26s, 85s, or until restart, in 3 of 4 test runs. (The whole-app teardown path didn't hit it because every context goes at once.)

Fix

The invalidator now takes wkWebViewBatchLock before closing the gate and detaching. That is the same order a round trip uses (the lock, then aliveVar inside the send), so it can't invert against one. Any round trip already under way finishes first, and none can start until the gate is closed.

• Bounded: if a round trip never completes (a wedged page), the invalidation would otherwise block forever. After ~5s it closes the gate without the lock, as before.
• No lost lock: the lock is acquired by polling tryTakeMVar under mask, not timeout around takeMVar, whose exception can land just after the take succeeds and lose the lock for good.
• Docs: jsaddleWebViewInvalidate's haddock now says it waits for in-flight round trips and must be called off the main thread, where replies are delivered.

Testing

Tested in leksah (macOS, several WKWebView windows; closing a window stops its reflex network, invalidates its context, then releases the webview). 15 windows were opened and closed in 5 rounds:

• the surviving window's 5s heartbeat never gapped more than 5.9s (before: 26s / 85s / indefinite stalls),
• all 15 WebContent renderer processes exited,
• no aborted frames.

Expected and unchanged: a closed context's leftover threads that try to send still get the context invalidated — batch dropped IOException, which ends that context's batch pump (stderr shows it as an uncaught exception).

Also: fix master's CI after #172

#172 added a batch-sender test suite to jsaddle-warp.cabal whose base has no upper bound. cabal check rejects that (missing-bounds-important, "Hackage would reject this package"), which fails every Haskell-CI job on master. 165fc80 bounds it (base <5), and cabal check is clean again. Master is merged into this branch (de25f2f) so the fix applies on top of #172.

Also: CI on GHC 9.6–9.14 (089f14a)

• Matrix: tested-with, and so the Haskell-CI matrix, is now GHC 9.14.1, 9.12.4, 9.10.3, 9.8.4 and 9.6.7, the latest release of each series. GHC 8.4–9.4 are no longer tested. Bounds are unchanged.
• Workflow: brought up to what haskell-ci 0.19.20261010 generates: Ubuntu noble container, cabal-install 3.16.0.0, actions/checkout@v7 / actions/cache@v6 (the v4 actions run on the deprecated Node 20), and cache keys named after the image. libwebkit2gtk-4.0-dev and libtinfo5 are dropped from apt: neither exists on noble, and none of the packages CI builds (jsaddle, jsaddle-warp, jsaddle-clib) needs WebKit. The file was edited by hand to match that output; haskell-ci regenerate with that version should reproduce it.