[heidari-dev]

Part of #15.

Kite runs on Windows: TUN mode through Wintun, the daemon as a service on a named pipe, and the desktop app on that pipe. The installer is the next PR.

What changes:

• crates/kite-win (new, Windows only) holds the unsafe: a protected directory for the keys, the pipe with its access list, the IP Helper route calls, the service glue. Everything else keeps forbid(unsafe_code).
• The daemon core is shared with Linux; daemon/sock.rs and daemon/pipe.rs hold what differs. The pipe lets in SYSTEM, administrators and the local group kite, refuses remote clients, and only an elevated administrator may pair. Clients open it at identification level.
• TUN mode: four routes on the Wintun adapter (0.0.0.0/1, 128.0.0.0/1, ::/1, 8000::/1), a host route for the relay only when it is reached through the default route, a catch-all NRPT rule so DNS goes to 1.1.1.1 through the tunnel. kite restore and the service at start remove what a killed run left.
• wintun.dll is never committed. scripts/fetch-wintun.ps1 pins the zip and the DLL by SHA-256; kite loads it by full path from its own directory and checks the signature.
• No kill switch on Windows: --kill-switch is refused, the app hides the toggle. Tracked in Windows: kill switch #88.
• Tray: Slint's own SystemTrayIcon (Windows notification area); ksni stays Linux-only. No new crate. The icon registers with the shell (Kite: Disconnected).
• Service account: LocalSystem. Making the adapter and changing routes need administrator rights; no narrower account can, see the threat model. The installer will cut the token's privileges.
• Dependencies: windows-sys 0.61 and windows-service 0.8 were already in the tree through tun and tun2proxy.

Memory (release build, Windows 11, no daemon running): tray only, 19.5 MB working set and 2.5 MB private; window open, 24.8 MB and 6.6 MB private.

Tested:

• cargo test --workspace and clippy on Windows; the Linux build of kite-cli and the other crates checks. New tests: pipe access and a second first instance refused, the caller admin check, junction refused by private_dir, TUN state parsing, the daemon over a pipe (limits, bad requests, kill switch refused), the desktop client over a pipe.
• CI job tun-windows runs scripts/tun-smoke.ps1 on a runner: it checks adapter, routes, DNS rule and the route to 1.1.1.1 while up, and that all of it is gone after kite disconnect and after the daemon was killed and kite restore ran.
• Not run here: TUN mode with a phone. That is the acceptance test.

Docs: docs/cli.md, docs/threat-model.md (Windows rows and gaps), apps/desktop/README.md.

Smoke test notes:

• The relay in the CI test runs on the same machine as kite, so the sockets it opens to the Internet enter the tunnel too and come back to it. That is why kite status shows over a hundred streams at 0 s: the runner's own traffic plus that loop. The connection from kite to the relay is not part of it; it goes to a loopback address, which no tunnel route covers, and setup adds no host route for loopback. With a real phone the relay is on another machine and there is no loop.
• A disconnect used to be able to hang under that load. Fixed in the product: when the tunnel is told to end, the routes and the DNS rule come off at once, the tunnel's tasks get 4 s and are then dropped, and the runtime is dropped with a 2 s limit instead of waiting for a task that does not stop.