fix: secure Windows reads reject foreign file owners

[joshavant]

What Problem This Solves

Fixes an issue where Windows secure-file consumers could accept a file with a restrictive ACL even when an untrusted principal owned the file and could later change that ACL. Ownership and ACL classification also depended on localized principal names in several paths, and extended Windows path namespaces were not classified consistently.

Why This Change Was Made

Resolve Windows owners and ACL principals to canonical SIDs through absolute system commands, then require ownership by the current user, LocalSystem, or Administrators for secure reads. Unknown owners, remote volumes, non-drive extended namespaces, lookup failures, and foreign owners fail closed. Exact extended drive paths such as \\?\C:\... remain supported.

This opens the 0.4.6 changelog section but intentionally leaves package publication/versioning to the normal post-merge release flow.

User Impact

Windows applications using fs-safe can rely on secure reads rejecting foreign-owned or unverifiable files. Local extended drive paths continue to work, while UNC, MUP, device, volume-GUID, and malformed namespaces remain blocked from local-only reads.

Evidence

• pnpm check on macOS: build, file-size and filesystem-boundary gates passed; 43 test files and 459 tests passed.
• Native Windows full check: build and gates passed; 43 test files, 327 tests passed, 136 platform-inapplicable tests skipped.
• Native proof accepted an Administrators-owned file and rejected a Builtin Users-owned file despite a restrictive ACL.
• Native readSecureFile proof passed for an exact extended local path (\\?\C:\...).
• Regression coverage rejects UNC, extended UNC, MUP redirector, volume-GUID, and device namespaces while allowing only exact extended drive-letter paths.
• Crabbox proof: https://crabbox.openclaw.ai/portal/runs/run_a31ae9e23c25
• Fresh automated review completed with no accepted or actionable findings; a DriveInfo compatibility concern was rejected because the exact Windows PowerShell path passed twice in native execution.

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix: secure Windows reads reject foreign file owners This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.