bench: intermittent per-command daemon restart ('daemon binary updated') adds ~200 ms to every fbuild command #1476

Found while landing #1464/#1466 (part of #1469).

Symptom

Some benchmark-build-comparison.yml runs show fbuild warm ≈ 251 ms (normally ≈ 46 ms) and cold inflated by about 200 ms. In those runs every fbuild command in benchmark.log prints daemon binary updated, restarting..., and the value holds steady across all 3 trials. It comes from the direct-HTTP acquisition path in crates/fbuild-cli/src/daemon_client.rs (ensure_direct_daemon_running → should_restart_daemon: same version, CLI-side sibling fbuild-daemon mtime > the daemon's reported source_mtime).

It is pre-existing and intermittent

• main nightly history has one run at warm 249.8 ms among 73 runs. That was before the zccache repin.
• Branch runs:
  • Bad: perf(build): repin zccache to 8475316 for the fast miss path (#1464) #1474's first dispatch (36234375809) and perf(build): probe each toolchain once per daemon (#1466) #1475's first dispatch (36238206814).
  • Good (46 ms, 0 restart lines):
    • four runs of the same or similar code (36235583298, 36236087937, 36236206722, 36236358015);
    • a forced cache-miss run (36239211262).
• A bad run is bad for its entire duration, which points to a per-job condition rather than per-command noise.

Ruled out

• An mtime change during the run: stat of target/release/fbuild-daemon (mtime and inode) stayed constant across a run. That was checked in the debug steps, which happened to be good runs.
• Inherited stdio holding Command::output() open: the daemon's fds 0/1/2 are /dev/null, /dev/null and daemon.log.
• soldr cache hit vs miss for fbuild-daemon: the forced-miss run was good.
• JSON f64 precision: serde_json round-trips f64 exactly.

Next step

Catch a bad run with RUST_LOG=fbuild_cli=info on the benchmark step. The daemon needs restart (daemon v… mtime=…, cli v… mtime=…) tracing line gives both sides of the comparison.

Independently, should_restart_daemon could compare a build identity (the git sha or a build id the daemon reports) instead of raw mtimes. That would make the same-version dev-rebuild check immune to anything that perturbs mtimes.