fix: make the Windows-hostile unit tests portable (#395)

The issue reports four failures against `b92ea0a` with 1417 tests. Run 32716362643 on `ecc60a4` has 1559 and fails seven: the crate grew since, and three more tests carried the same kind of assumption. All seven are test-harness portability rather than product defects, which is what the issue already concluded for its four.

`echo` and `false` are shell builtins on Windows rather than executables on PATH, so `Command::new` cannot spawn either. Gating those two tests to Unix would have been easier and wrong, because `execute_command` runs on Windows in production against nvidia-smi and wmic, so it is worth testing there. Each platform now names a program it actually has, `cmd /C echo` and `cmd /C exit 1`.

`/bin/ls` carries no drive letter and so is not absolute on Windows, which rejected it before reaching the check the test is about. The traversal case moved to a per-platform literal for the same reason: a Unix-shaped path is refused for absoluteness first, leaving the `..` branch unexercised there. `/tmp` does not exist on Windows either, so the atomic-write test now uses `std::env::temp_dir()`.

The tilde test forced `HOME`, but `expand_tilde` resolves through `dirs::home_dir()`, which reads `USERPROFILE` on Windows, so the override changed nothing and the assertion compared against the real profile directory. It now compares against `dirs::home_dir()` directly, the shape `common::paths`'s own tilde tests already use, which also removes the `unsafe` env mutation whose comment admitted it was accepting a data race.

The two os-error-32 failures are one Windows rule in two places: it refuses to open a path another live handle owns. The WAL test kept its write handle open across the replay, and the bundle test handed `write_bundle` the path of a still-open `NamedTempFile`. The first drops the handle explicitly, the second writes into a `tempdir`. Unix permits both, which is why neither was noticed.

Nothing here matches on OS error text. The runner reported error 32 in Korean, so its locale is ko-KR, and an assertion on the message string would pass in one locale and fail in another.

Verified on the real Windows runner, run 32720791131: `cargo test --lib` reports `1566 passed; 0 failed`, where the same runner reported `1559 passed; 7 failed` before this branch. The job is still red there because `cargo clippy` has its own denials, fixed separately in #394.

On Linux: `cargo fmt --check` clean, `cargo test --lib` 1684 passed, `cargo test --bin all-smi` 1860 passed.

Closes #366