[package-deps-hash] Skip Windows reserved device names when computing repo state (fixes #5604)

[LeSingh1]

Summary

getRepoState/getDetailedRepoStateAsync feed the set of locally-modified files through git hash-object. When one of those files happens to be a Windows reserved device name (nul, con, aux, com1-com9, lpt1-lpt9) — typically a stray artifact from a misdirected shell redirect — git hash-object cannot open the path and the entire spawnGitAsync call exits with:

fatal: could not open 'apps/admin-powerplatform-microsoft-com/nul' for reading: No such file or directory

aborting rush build (and any other Rush command that consults repo state). This is increasingly common as AI coding agents leave nul artifacts behind, per the issue body.

Fix

Added an internal isWindowsReservedPath(filePath) helper to getRepoState.ts and use it in getDetailedRepoStateAsync's getFilesToHash generator to skip such files when process.platform === 'win32'. The helper:

• handles paths with or without an extension (nul, nul.txt, aux.log.bak);
• accepts either / or \\ separators;
• is case-insensitive (matches Win32 semantics);
• only matches the final path segment (so packages/nul-suffix/index.ts is not affected).

Tracked files cannot use these names on a Windows checkout (git refuses to materialize them), so filtering on the working-tree side is sufficient.

Tests

Added 4 unit-test cases under libraries/package-deps-hash/src/test/getRepoState.test.ts covering bare names, names with extensions, nested paths with both separator styles, and negative cases (null, console.ts, com.ts, lpt10, packages/nul-suffix/...).

Logic verified locally with a node script (15/15 cases pass). I did not run the full Rushstack heft test suite locally; if CI catches anything I'll iterate.

Changeset

patch for @rushstack/package-deps-hash.

Issue

Fixes #5604