Race condition hot restarting on-save

I don't know if this affects Flutter web or not, I see it using the daemon directly. When I modify a HTML file in VS Code we trigger hot-reload-on-save. We wait for 200ms to ensure there are no other saves (so that Save All doesn't trigger lots of reloads) and then send an `app.restart` to the daemon.

Despite the 200ms delay, it seems that the hot restart is processed before the rebuild, and this results in the browser reloading with the old contents of the HTML file (I guess it's not read directly from the disk, but from an intermediate built location?).

The output looks like this:

```
Restarted application in 88ms
[INFO] About to build [web]...
[INFO] Updating asset graph...
[INFO] Updating asset graph completed, took 3ms
[INFO] Running build...
[INFO] 1.0s elapsed, 5/5 actions completed.
[INFO] Running build completed, took 1.0s
[INFO] Caching finalized dependency graph...
[INFO] Caching finalized dependency graph completed, took 324ms
[INFO] Succeeded after 1.3s with 8 outputs (7 actions)
[INFO] ------------------------------------------------------------------------
```

This is running on macOS. I'm not sure where the delay comes from - does webdev do its own debounce/delay on its watcher to also avoid triggering too much? If so, once the first one triggers could it stall processing things like hot reloads (eg. just make it seem like the hot reload took longer, because it waited for the build, then reloaded afterwards)?

Start by tracing the daemon's hot-reload-on-save flow, the 200ms save debounce, and the app.restart request alongside webdev's watcher and build sequence. Reproduce the macOS VS Code case and compare the ordering in the output; done means the rebuilt HTML is available before the browser reloads and no stale contents appear.

Written by the indexing model from the issue text.