fix: Windows init and daemon startup (issue #5)

Three related bugs caused "wx init" and daemon startup to fail on Windows:

1. init.rs: create ~/.wx-cli/ before writing all_keys.json (was created
   only before config.json, so first write failed with ENOENT)

2. transport.rs (Windows): daemon.log was always empty because stderr
   was never redirected, and log file open silently fell back to null
   when parent dir didn't exist. Now mirror the Unix version: create
   parent dir, try_clone to redirect both stdout and stderr.

3. server.rs (Windows): interprocess GenericNamespaced auto-prepends
   \\.\pipe\ on Windows. Passing the full path caused a double-prefixed
   pipe name that clients (using raw \\.\pipe\wx-cli-daemon) could
   never connect to, leading to the 15s startup timeout.

src/daemon/server.rs

@@ -92,12 +92,13 @@ async fn serve_windows(
         tokio::prelude::*, GenericNamespaced, ListenerOptions,
     };
 
-    let pipe_name = r"\\.\pipe\wx-cli-daemon";
-    let name = pipe_name.to_ns_name::<GenericNamespaced>()?;
+    // interprocess 的 GenericNamespaced 在 Windows 上会自动拼接 `\\.\pipe\` 前缀，
+    // 这里必须传相对名；client 端用 `\\.\pipe\wx-cli-daemon` 直接打开可以对上
+    let name = "wx-cli-daemon".to_ns_name::<GenericNamespaced>()?;
     let opts = ListenerOptions::new().name(name);
     let listener = opts.create_tokio()?;
 
-    eprintln!("[server] 监听 {}", pipe_name);
+    eprintln!("[server] 监听 \\\\.\\pipe\\wx-cli-daemon");
 
     loop {
         let conn = listener.accept().await?;