Windows: daemon stop must taskkill the whole process tree (/T)

[danielhertz1999-bit]

Problem

iai_mcp daemon stop on Windows can leave a child process alive and still holding the hippo DB lock, so a subsequent restart wedges.

The Windows stop path did:

os.kill(pid, _signal.SIGINT)          # (1)
... poll until pid dies or timeout ...
if _is_pid_alive(pid):
    subprocess.run(["taskkill", "/F", "/PID", str(pid)])   # (2) no /T

Two problems compound:

1. On Windows os.kill(pid, SIGINT) is not a signal — Python maps any non-CTRL_* value to TerminateProcess, which hard-kills the parent process only. Any child the daemon spawned (a worker interpreter, a maturin build, etc.) is orphaned and keeps running — and keeps its handle on ~/.iai-mcp/hippo/.lock.
2. Because TerminateProcess kills the parent immediately, the poll loop sees the pid gone and returns before the taskkill escalation runs. And even when it did run, taskkill /F /PID (no /T) only kills that one pid — by then childless.

Net effect: a "stopped" daemon can leave an orphan holding the lock, which then blocks the next daemon from acquiring it.

Fix

Replace the SIGINT-then-escalate sequence with a single taskkill /F /T /PID <pid>. /T terminates the daemon together with its child process tree, while that tree is still intact. schtasks /End still runs first. This is a hard kill, but the old path was already a hard kill on Windows (TerminateProcess) — no graceful-shutdown behavior is lost, and the tree is now handled correctly.

POSIX (macOS/Linux) stop paths are untouched.

Test

The Windows stop path previously had zero coverage (existing stop tests are macOS/Linux, or @skipif no-SIGKILL). The new test drives cmd_daemon_stop with platform.system() == "Windows" and asserts it issues taskkill /F /T /PID after schtasks /End, and never calls os.kill (which would orphan the tree). Verified both ways: passes on the fix, fails against the pre-fix source (which shows the os.kill(SIGINT) + taskkill /F /PID sequence).