fix(daemon): use hash-only Windows named-pipe name

[BB-fat]

Motivation

Fixes #75 — on Windows machines whose username contains an apostrophe (e.g. z'z'f'l'g'y), the CLI can never reach the daemon over its named-pipe IPC. The daemon logs that it is listening on \\.\pipe\bsk-daemon-z'z'f'l'g'y-<hash>, yet every client CreateFileW on that exact name fails with ERROR_FILE_NOT_FOUND / ERROR_PATH_NOT_FOUND.

Root cause

crates/bsk-cli/src/daemon/paths.rs embedded %USERNAME% verbatim in the pipe name (\\.\pipe\bsk-daemon-{user}-{hash}). Although Microsoft documentation says any character except backslash is legal in a pipe name, NPFS behaviour for such names diverges in practice between create and open: CreateNamedPipeW succeeds while clients opening the same name get FILE_NOT_FOUND. Both sides were verified to use byte-identical names (the CLI reads the name from daemon.json, never recomputes it), so the divergence sits at the Win32/NPFS boundary with the raw special characters.

Changes

• The pipe name is now hash-only: \\.\pipe\bsk-daemon-{hash}. The hash already covers user + bsk_home, so uniqueness and per-user / per-BSK_HOME isolation are exactly as before — but no raw username characters (apostrophes, spaces, non-ASCII) ever reach NPFS.
• The pure name-rendering is factored into a render_pipe_name(user, home) helper so its output charset is unit-testable on any host.
• New unit tests: safe-charset assertion for usernames with apostrophes/spaces/Unicode/backslashes, plus determinism and per-(user, home) uniqueness.

Backward compatibility

The pipe name is exchanged exclusively through daemon.json (written by the daemon, read by the CLI — the CLI never computes pipe_name() itself; verified there are only two call sites, both inside the daemon process). So any old/new CLI↔daemon combination keeps working: whichever side runs the new code simply writes/reads a different name string.

Other username-in-name sites

Grepped the whole CLI/protocol crates for %USERNAME%, USER, LOGNAME, whoami, user*name: this was the only place embedding the OS username into an IPC/filesystem name. Unix socket paths live under $HOME/.bsk/run/ where apostrophes are legal path characters, so no change needed there.

Test plan

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo test --workspace --locked (new daemon::paths tests included)
• CI has only Ubuntu runners; the NPFS behaviour itself can only be exercised on Windows. The fix is verified by unit tests pinning the output charset plus the code-path analysis above — a confirmation from the issue reporter on a real affected machine would be appreciated.