auto-forward: Windows detach/signaling path (+ windows-latest CI validation job)

[pofallon]

Tracked deferral from the up --auto-forward feature (spec 015-auto-forward-ports, task T054; shipped in #188). v1 is Unix-only; this adds Windows host support for the detached forwarder.

Goal / acceptance

deacon up --auto-forward detaches a forwarder and is reaped correctly on Windows hosts (same external behavior as Unix).

Hidden issues / gotchas

• No setsid/dup2/kill on Windows. The Unix path (crates/core/src/port_forward/daemon.rs) re-exec's the child and has it call nix::unistd::setsid() then dup2 its own stdio onto the per-container log. Windows has no session/dup2-self-redirect equivalent.
• Detach model is inverted. On Windows the cleaner approach is the parent spawning the child already-detached: std::os::windows::process::CommandExt::creation_flags(DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP) with the child's stdio redirected to the log at spawn time (crates/deacon/src/commands/up/forward.rs::spawn_daemon). So daemon::daemonize() becomes a near-noop on Windows.
• Signaling differs. pid_alive/terminate_pid can't use POSIX signals — need OpenProcess/GetExitCodeProcess for liveness and TerminateProcess (or GenerateConsoleCtrlEvent for a graceful path) for reaping, via windows/windows-sys gated cfg(windows).
• Cannot be behaviorally verified in our Linux+Docker CI. GitHub-hosted windows-latest runners can't run our Linux-container Docker integration tests — see the disabled matrix entry in .github/workflows/ci.yml ("Windows disabled until bespoke runner with Docker support is available"). We do already build the Windows deliverable on windows-latest in release.yml (MSVC targets + a deacon.exe --version smoke run).

Recommended path forward

1. Implement a #[cfg(windows)] detach/signaling path: parent-side detached spawn + stdio→log redirect; OpenProcess/TerminateProcess-based liveness/terminate; daemonize() no-op.
2. Add a windows-latest CI job to ci.yml that runs cargo build + the hermetic unit tests (parser, registry loopback-bind allocation, attributes, marker, new Windows process-helper unit tests). This is a compile + unit gate — it catches the bulk of breakage pre-launch even though it can't run the Docker e2e path.
3. Land it as "CI-validated, not behaviorally verified" until a Docker-capable Windows runner exists; track the e2e verification as a sub-task.

Out of scope

Behavioral e2e validation on Windows (blocked on a Docker-capable Windows runner).