fix: normalize Windows path keys in harness generation

[rudycelekli]

The harness generator indexes copied files using native path.relative() results, then looks them up using slash-separated skill paths. Windows relative paths contain backslashes, causing rendering to crash at files.get(path).bytes. Native disk keys would also disagree with generated keys during --check.

Normalize keys to POSIX separators at both boundaries while keeping filesystem paths native. Add a regression that runs the full production check with native and actual path.win32 relative-path semantics, and run it in CI.

Validation: both regression cases pass; the unchanged generator passes the native case and fails the Windows-separator case. Separate production write runs generated 139 files each, with all filenames, bytes and executable flags matching the committed tree. Tests ran on macOS; this verifies Windows path semantics, not a native Windows filesystem. AI-assisted implementation and testing.

---

Note

Low Risk
Build/CI script changes only; no runtime product behavior beyond fixing cross-platform harness generation.

Overview
Fixes harness tree generation and --check on Windows by normalizing path.relative() map keys to POSIX (/) separators while leaving real filesystem paths native.

In generate-pstack-harness-trees.mjs, both the rendered file index and the on-disk comparison now use .split(sep).join(posix.sep) so lookups like skills/.../SKILL.md match on Windows (where relative paths use backslashes).

Adds generate-pstack-harness-trees.test.mjs, which runs the full production --check in a VM with native paths and with node:path stubbed to win32.relative / win32.sep. CI runs this test in validate-plugins.yml.

^{Reviewed by Cursor Bugbot for commit e56550c. Bugbot is set up for automated code reviews on this repo. Configure here.}