fix(daemon): startup timeout can abandon detached child

[PierrunoYT]

Summary

zero daemon start detaches and releases the child process before daemon readiness is established. If the readiness wait times out, the command reports failure but no longer owns the process, so the detached daemon may become ready later and interfere with retries.

This tracks AUD-009 from the July 18 codebase audit.

Affected code

• internal/cli/daemon.go:138-176

Current behavior

The startup path releases the detached child before the readiness check completes. When startup takes longer than the five-second readiness timeout:

1. the CLI reports startup failure;
2. the child remains detached and is not terminated or reaped by the caller;
3. the daemon may bind successfully after the timeout; and
4. a retry can encounter an unexpected existing daemon process.

Expected behavior

The startup command should retain ownership of the exact child until readiness succeeds or startup definitively fails.

On timeout it should:

1. perform one final readiness check to avoid racing a just-ready daemon;
2. terminate the exact process it launched if readiness still fails;
3. reap that process; and
4. report the timeout only after cleanup completes.

The process should be released only after readiness succeeds.

Suggested tests

• A child that becomes ready before the timeout is released and remains running.
• A child that never becomes ready is terminated and reaped on timeout.
• A child that becomes ready at the timeout boundary is detected by the final readiness check and is not killed.
• A retry after timeout does not encounter an abandoned process from the failed attempt.

[PierrunoYT]

I'm working on a fix for this.