test(skill-install): expect the documented Hermes home on Windows

[kaanisthatyou]

Closes #312.

Problem

cargo test --workspace fails on native Windows in two skill_install::harness tests. Reproduced on Windows 11 (10.0.26200) at c1e5052:

test skill_install::harness::tests::detects_hermes_from_home_layout ... FAILED
test skill_install::harness::tests::skills_dirs_match_harness_spec ... FAILED

  left: "C:\Users\ADAS\AppData\Local\hermes\skills"
 right: "/home/user/.hermes/skills"

test result: FAILED. 8 passed; 2 failed

Both assert the POSIX ~/.hermes layout, but hermes_home_for_user_home deliberately mirrors Hermes's own get_hermes_home() and resolves %LOCALAPPDATA%\hermes on Windows — it never derives the path from home there. The implementation is right; the assertions did not account for the branch it documents.

Every other assertion in skills_dirs_match_harness_spec survives on Windows because they all reduce to home.join(".<name>") and Path equality compares components, so the separator does not matter. Hermes is the one entry that does not.

Because this is the lib test target, cargo stops there and the integration tests never run.

Changes

• expected_hermes_home test helper mirrors the documented contract — %LOCALAPPDATA%\hermes on native Windows, else ~/.hermes — so both tests build their expectation the same way instead of hard-coding one platform's layout.
• detects_hermes_from_home_layout points LOCALAPPDATA at its temp home for the resolution, then creates the directory the resolver will actually look at. Creating %LOCALAPPDATA%\hermes for real would write into the developer's profile, and clearing the variable would only move the assertion to the home\AppData\Local\hermes fallback. The variable is restored before the assertions run, so a failing assertion cannot leave it pointing at a deleted temp directory for the tests that follow. The test already takes lock_harness_env(), so the serialisation this needs is in place.
• CI: the windows-daemon job runs filtered test paths and none of them selected skill_install::harness, which is why Windows CI never caught this. Added one step next to the other --lib ones.

No production code changed.

Tests

cargo test -p bsk --lib skill_install::harness on Windows 11, Rust 1.94.1:

• before: 8 passed; 2 failed (the two above)
• after: 10 passed; 0 failed

cargo fmt --check and cargo clippy -p bsk --lib --all-targets are clean.

cargo test --workspace now gets past the lib target, and one integration test fails on this machine: browser_list_ordering::browser_list_and_multiple_browsers_error_share_stable_ordering, on connect IPC named pipe ... (os error 2). That one is environmental rather than related to this change — it fails identically with my changes stashed, since it needs a daemon this machine is not running. Worth knowing that fixing the lib tests is what makes it visible at all.

Unrelated observation

While verifying, every dev build left crates/bsk-cli/skill/SKILL.md modified in the working tree. That is crates/bsk-cli/build.rs doing what it says — syncing the repo-root skill into the packaged copy — but the two committed blobs have drifted (d8c1110 vs 47bea20), so the copy is a real write rather than a no-op and every contributor gets a dirty tree after cargo build. I left it out of this PR; happy to open a separate one that commits the synced copy if you'd like.