fix(mcp): publish a restarted hyperd endpoint to daemon.json before STATUS

[StefanSteiner]

Fixes #284

Stacked on #278. This branch is based on #278's rebased head (236e957),
so its diff here includes #278's two commits. It targets main and should be
merged after #278; once #278 lands, this reduces to the single commit
fix(mcp): publish a restarted hyperd endpoint to daemon.json before STATUS.
Deliberately kept out of #278, which is a separate concern.

Why

test (ubuntu-latest) has been red on main since 56bc0d0, and because the
failure is a race it randomly reddens the ubuntu leg of every open PR —
including #278, whose own run was otherwise 16/17 green.

commit	test (ubuntu-latest)
c9bacf2	success
06c5da1	success
56bc0d0 (#279 merge)	failure
61fc766 (#280 merge)	failure

56bc0d0 re-enabled eight daemon crash-and-restart tests on Linux and Windows
by narrowing #[ignore] to #[cfg_attr(target_os = "macos", ignore)]. Both
red runs fail identically: engine_recovers_after_hyperd_killed at
daemon_tests.rs:1473:67 with Connection refused against a hyperd
endpoint.

What was actually wrong

The prior investigation root-caused this as try_restart_hyperd publishing the
new endpoint to STATUS before rewriting daemon.json, with the test's STATUS
readiness gate racing Engine::new's file-based discover(). I could not
confirm that, and the measurements contradict it. Two things are wrong here,
and the ordering hazard is not the one breaking CI.

1. The readiness gate never waits for the restart — this is the CI failure

wait_for_endpoint_change_or_recovery returned as soon as the endpoint STATUS
reported was TCP-connectable, never comparing it against the pre-kill endpoint
despite its name. For a few milliseconds after SIGKILL the doomed hyperd's
listening socket still completes inbound connections, and the callers poll
immediately after the kill — while the daemon's 5s monitor tick has not fired,
so STATUS still advertises the old process. The gate therefore returned on its
first attempt carrying the pre-kill endpoint, and the caller then raced the
kernel tearing that socket down.

The wall clock alone proves the failures precede any restart: every failing
run finished in ~0.53s, every passing run in ~5.47s, against a 5s monitor
tick. Instrumented, the failing runs are explicit — and note the discovery file
and STATUS agreed, which is what rules out the ordering hypothesis:

DIAG pre_kill_endpoint=127.0.0.1:50993
DIAG gate_returned=127.0.0.1:50993 after=946.708µs same_as_pre_kill=true
DIAG discover_file_endpoint=Some("127.0.0.1:50993")
-> panicked ... Connection refused

The daemon in fact behaved correctly in every failure: a client that finds a
dead hyperd through discovery is supposed to get a connect error and report
it (Engine::new calls report_hyperd_error_to_daemon on exactly this path).
The test asserted success without waiting for the recovery it claimed to
await.

wait_for_live_hyperd_after_kill replaces it and gates in two phases: first
wait for the killed endpoint to stop accepting connections, proving the old
hyperd is gone; only then accept the endpoint STATUS advertises. It
deliberately does not require the endpoint to change — the OS may hand
the replacement the same port, and a changed-endpoint gate would then wait out
its whole timeout on a healthy restart.

2. The daemon published a restarted endpoint in an unsafe order — real, but latent

try_restart_hyperd copied the new endpoint into the in-memory DaemonInfo
that STATUS serves, released that lock, and only then rewrote daemon.json.
Since discovery::discover() reads the file, a client discovering inside that
window connected to the hyperd just dropped. The write failing was worse
than the window: the error return happened with the new endpoint already
published to STATUS and the replacement HyperProcess dropped on the way out,
leaving STATUS durably naming a hyperd the daemon itself had killed.

Now the discovery file is persisted first and DaemonInfo flipped second, both
under one info_arc lock, so observing the new endpoint through either channel
implies a live hyperd and no STATUS reader can catch an endpoint the file has
not committed. write_discovery_record is already atomic (temp file +
fs::rename), so this is purely an ordering change.

To be explicit: in 32 instrumented runs the file and STATUS agreed in every
case, including all failures. This is fixed because it is a genuine
correctness bug in its own right, not because it reddens CI.

Measurements

Run on macOS via --ignored, driving the test binary in a loop. Baseline on
pristine main (61fc766); "after" on this branch.

test	baseline	after
engine_recovers_after_hyperd_killed	4 failures / 20 runs	0 failures / 50 runs
hyperd_monitor_detects_killed_hyperd_and_restarts	0 failures / 20 runs	0 failures / 20 runs
client_report_triggers_restart_after_kill	0 failures / 20 runs	0 failures / 20 runs

All four baseline failures were byte-identical and matched CI exactly.

The same gate was silently making a second test vacuous

hyperd_monitor_detects_killed_hyperd_and_restarts never failed, but 5 of
its 20 baseline runs finished in ~0.46s instead of ~5.4s — the gate handed
back the pre-kill endpoint and the follow-up probe caught the socket before
teardown. Those runs asserted nothing about a restart: the test passed without
the behavior under test ever occurring. After the fix, 0 of 20 are sub-1s;
all take the full restart time. client_report_triggers_restart_after_kill
showed 0 vacuous runs only by accident — its REPORT_HYPERD_ERROR round-trip
happens to outlast the teardown window — and is fixed alongside the others.

Verification

cargo fmt --all -- --check                                          exit 0
cargo clippy --workspace --all-targets --all-features -- -D warnings exit 0
cargo test -p hyperdb-mcp --lib                     137 passed, 0 failed
cargo test -p hyperdb-api --test pool_tests          16 passed, 0 failed
cargo test -p hyperdb-mcp --test daemon_tests        52 passed, 0 failed, 8 ignored
npx markdownlint-cli2                                0 issues in 68 files

Because these eight tests are #[cfg_attr(target_os = "macos", ignore)], the
plain daemon_tests gate skips them on macOS (8 ignored above). To get
Linux-equivalent coverage locally I also ran the suite with
-- --include-ignored --test-threads=1 three times: 60 passed / 0 failed
twice, and one run failed on daemon_mode_engine_connects_to_shared_hyperd
with TestDaemon did not start within 150s — which is the pre-existing,
macOS-specific condition the original #[ignore] reason names verbatim
("daemon startup exceeds 150s timeout"), reproduced only because I forced the
macOS-ignored tests to run under load. It is unrelated to this change and is
not the failure mode seen on Linux CI.