BUG: --local mode returns N/A for workflow/policy checks on Windows due to path separator handling

[Shtirmann]

Describe the bug
When running scorecard --local <dir> on Windows, several checks always return N/A or 0 regardless of repository contents:

• Dangerous-Workflow = -1 ("no workflows found")
• Token-Permissions = -1 ("no tokens found")
• Pinned-Dependencies = -1 ("no dependencies found")
• Security-Policy = 0 for policies in subdirectories (e.g. .github/SECURITY.md)

Reproduction steps
Steps to reproduce the behavior:

1. On a Windows machine, create a directory with a license and a workflow:
   • LICENSE (any OSI license text)
   • .github/workflows/ci.yml (any valid workflow, e.g. permissions: contents: read)
   • .github/SECURITY.md (any security policy)
2. Run: scorecard --local . --checks Dangerous-Workflow,Token-Permissions,Pinned-Dependencies,Security-Policy,License --format json
3. Observe that Dangerous-Workflow, Token-Permissions, Pinned-Dependencies are N/A and Security-Policy is 0, while License is detected.

Expected behavior
Workflow- and policy-based checks should produce the same results as on Linux/macOS. With both trimPrefix and IsWorkflowFile normalized to forward slashes (filepath.ToSlash), a local build returns real results on Windows:

Check	Before (Windows)	After (Windows)
Dangerous-Workflow	N/A	10
Token-Permissions	N/A	analyzed (flags excessive permissions)
Pinned-Dependencies	N/A	analyzed (flags unpinned actions)
Security-Policy (subdir)	0	detected

The existing test clients/localdir.TestClient_GetFileListAndContent already encodes the forward-slash contract and currently fails on Windows on the path assertion (line ~188), which confirms the expected behavior.

Additional context

• Reproducible on the latest main (both trimPrefix and IsWorkflowFile are unchanged from affected releases such as v5.1.0).
• The fix is a no-op on Linux/macOS, since filepath.ToSlash does nothing where the separator is already /.
• I have a fix ready and will open a PR referencing this issue.
• Note (separate, not part of the fix): the clients/localdir testdata fixtures fail content assertions on Windows checkouts with core.autocrlf=true (CRLF vs LF) — a test-fixture concern independent of this bug.