fix: the boot poll could not detect the thing it exists to detect

[zmaril]

Reported as "the preview loads but nothing happens when I click".

The real bug

The /boot poll had no timeout:

const r = await fetch("/boot", {cache: "no-store"});   // ← unbounded

A stopped machine doesn't refuse the request — the host holds it open while waking. So the fetch neither succeeded nor threw, catch never ran, misses stayed at zero, and the disconnect banner never showed. The websocket goes silent rather than closing, so that detector missed it too.

Both paths assumed failure looks like an error. Here it looks like patience — and a server that is slow and a server that is gone are the same thing to someone clicking.

const BOOT_TIMEOUT = 3000;
const r = await fetch("/boot", {
  cache: "no-store",
  signal: AbortSignal.timeout(BOOT_TIMEOUT),
});

Bounded, and shorter than its own 4s interval so polls take turns rather than stacking behind a hanging one. Two misses (~8s) shows "Server unreachable — waiting…"; the existing boot-id branch reloads once the machine is genuinely up.

The test reads both numbers out of the generated page rather than trusting the comment, and I checked it bites:

the boot poll waits 5000ms but fires every 4000ms, so they overlap

A correction, from the Fly logs

My first version of this PR also widened the preview health-check grace period from 10s to 45s, on the theory that a cold start was slow. The logs disprove that:

18:01:57  machine started in 2.29s
18:02:00  demo mode: seeded 7 runs
18:02:00  Health check on port 8080 is now passing
18:02:00  machine became reachable in 2.52s

Startup is ~3 seconds, seeding included. Ten seconds of grace was never too short and 45 would have helped nothing. The ~36s wake is Fly's proxy failing to start a stopped machine — its own dashboard says "Proxy is having trouble reaching app" — which is the other side of the wire from this repo. That change is reverted.

The boot-poll fix stands on its own: whatever makes the wake slow, the detector couldn't fire.

One thing the logs did earn

The daemon binds 0.0.0.0 and printed powderman on http://localhost:8080. That's the exact string Fly Doctor pattern-matches to report "App is not listening to the expected port… make sure your app is listening on 0.0.0.0 and not localhost" — so a line meant to be helpful was arguing for a bug that wasn't there, in a console someone reads while debugging. It prints the bind address now.

166 tests pass; fmt clean, clippy clean under -D warnings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XjCx5QszLXroGYh1YBxybw

[github-actions]

powderman preview

https://powderman-pr-125.fly.dev

The workbench, live: split/join/swap areas, the F3 palette, the widgets, themes, tooltips, the status bar.
The fleet and run execution are inert here (a Fly machine has no herdr) — this is for driving the interface.

On branches with the MCP server, point an agent at it:

claude mcp add --transport http powderman-preview "https://powderman-pr-125.fly.dev/mcp"

Updated on every push. Destroyed when this PR closes.