Fix Windows trust-check failure on 9P network shares by handling ERROR_INVALID_FUNCTION

[Copilot]

Fixes issue #2128 where gitoxide fails to open repositories on Windows when they are accessed via 9P network shares.

Problem

On Windows, when a repository is located on certain network filesystems (particularly 9P shares), the GetNamedSecurityInfoW Windows API function fails with "Incorrect function" (error code 1 / ERROR_INVALID_FUNCTION). This causes gitoxide to completely fail when trying to determine repository trust level, preventing the repository from being opened at all.

Couldn't get security information for path 'Z:\home\user\repo\.git' with err Incorrect function. (os error 1)) path="Z:\\home\\user\\repo"

Solution

Instead of failing hard when GetNamedSecurityInfoW returns ERROR_INVALID_FUNCTION, the code now gracefully handles this case by:

1. Detecting the specific ERROR_INVALID_FUNCTION error condition
2. Returning Ok(false) (indicating the path is not owned by the current user)
3. This results in "reduced trust" rather than complete failure
4. Allows the repository to be opened, albeit with appropriate security restrictions

Changes

• Core fix in gix-sec/src/identity.rs:

  • Added ERROR_INVALID_FUNCTION to Windows API imports
  • Enhanced error handling in is_path_owned_by_current_user() to specifically catch this error
  • Added detailed comments explaining the behavior for 9P network shares

• Enhanced test coverage:

  • Added test for non-existent paths to ensure other error conditions still fail appropriately
  • Added comprehensive trust behavior verification test with proper assertions
  • All existing tests continue to pass

Security Considerations

This change maintains the security model by defaulting to the safer "reduced trust" state when ownership cannot be determined, rather than assuming trust or failing completely. Other error conditions continue to cause hard failures as expected.

The fix ensures Windows users can access repositories on 9P network shares while preserving gitoxide's security guarantees.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[EliahKagan]

For the reasons described in #2128 (comment), I think the approach here of falling back to Ok(false) for the relevant error code is good.

However, as described in more detail in the "Implications for PR #2129" section of that comment, I think the commit with the fix should--perhaps when rebasing anyway to add fix:--be reworded to avoid describing the currently broken case as "mounted paths" or "mounted drives," because:

• Shares generally work; it is only 9P shares that do not.
• Whether a mapped drive letter is used to access the share has no impact.

[Byron]

@copilot Don't println in tests, use assertions with third arguments instead, like assert_eq!(a, b, "format {} string").

[Copilot]

Fixed in commit 0d664ac. Replaced all println statements with proper assertions using third arguments for better error messages.

[Byron]

@copilot Remove this, makes no sense.

[Copilot]

Removed the redundant Trust::from_path_ownership test in commit b2dca1b. The test was duplicating functionality already covered by the is_path_owned_by_current_user test above it.

[Byron]

@EliahKagan I think my review will remove the worst bits of this PR, but I am happy that maybe there is something salvageable. Could you take it from here?
Please do feel free to redo the PR under your name as well.

[Copilot]

For the reasons described in #2128 (comment), I think the approach here of falling back to Ok(false) for the relevant error code is good....

Thank you for the clarification. I've updated the commit message to be more specific about 9P network shares rather than general "mounted paths" or "mounted drives", since the issue is specific to certain network filesystems like 9P shares and not all mounted drives.