fix: clear the clippy denials on native Windows (#394)

Nine denials, not the four the issue lists, and the gap has the same cause as the undercount in #366: nothing could see past the first thing that stopped the build. Clearing the four in the lib let clippy reach the bin for the first time, where it found five more, and one of those had to be cleared before the rest were even reachable.

Three of the original four are `clippy::collapsible_if`, each collapsing to a let-chain, which this crate already uses elsewhere and edition 2024 supports at the pinned MSRV. The `amd_ryzen.rs` one is worth a note: `take()` runs whether or not the second condition holds, so the lock is cleared even when the library was never initialised and only the uninit call is conditional. A let-chain preserves that order exactly.

The fourth is the unused `use super::*` in `command_timeout.rs`'s test module. Deleting it breaks Linux, where it is used, so the fix is a gate. The module became `#[cfg(all(test, unix))]` rather than gating the import alone: both tests drive Unix programs, and gating only the import would leave `output_cap_leaves_small_outputs_alone` compiled on Windows with its entire body behind `#[cfg(unix)]`, a test reporting `ok` while asserting nothing. That does leave the output cap without Windows coverage, which needs a Windows program emitting an unbounded stream and is a test to write rather than a lint to silence.

`result_large_err` on the two SSH collector signatures was next, and the conventional fix would shrink nothing. Measured: `ConnectionStatus` is 184 bytes, the `Ok` variant carries the same struct plus a `Vec` at 208, and the `Result` is 208 whether or not the `Err` is boxed. Boxing would add a heap allocation per failed host and remove zero bytes. Both functions therefore take `#[allow(clippy::result_large_err)]` carrying that measurement, and `boxing_the_error_would_not_shrink_the_result` pins it, because suppressing a lint on a claim about sizes is only honest if the claim is checked. If the `Ok` side ever shrinks, that test fails and the suppression stops being justified.

The five in the bin split two ways. Three are items used only by tests in code a non-test Windows build still compiles, and none of them should be deleted: `Snapshot::is_empty` is asserted on in its own module's tests and `AdapterLuid::new` has ten call sites, all assertions. Their module is gated `cfg(any(target_os = "windows", test))`, so off Windows it exists only under `test` where they are used, and a non-test Windows build is the single configuration that compiles them with no caller. `is_serving` reaches the same place differently: its `#[cfg_attr(not(windows), allow(dead_code))]` was copied from `wait_until_serving`, which the Windows service host really does await, so keying on the platform silenced every target except the one where the item is genuinely dead. All three now key on `not(test)`.

The other two are ordinary cfg drift in `main.rs`. `SocketSetting` is read only inside the `#[cfg(unix)]` socket block, so its import is gated the same way, and `interval` is consumed only by the cfg-gated macOS and Linux initialisers, so the binding itself is gated rather than the warning allowed. A future consumer on another target then fails to compile instead of quietly reintroducing dead code.

Verified on the real Windows runner, run 32723212182: `cargo clippy` reports `success`. The job is still red there because `cargo test --lib` had its seven failures, fixed separately in #395.

On Linux with rustc 1.98.0: `cargo clippy --all-targets -- -D warnings` passes with no findings, where `main` had two; `cargo fmt --check` clean; `cargo test --lib` 1684 passed and `cargo test --bin all-smi` 1861 passed.

Closes #367