files: executable discovery uses the Unix execute bit, so no plugin is discovered on Windows

[peteski22]

DiscoverExecutablesWithPaths gates discovery on the Unix execute bit (internal/files/files.go:77):

if info.Mode().IsRegular() && info.Mode().Perm()&0o111 != 0 {

Windows has no execute bit. Go synthesizes permissions from the read-only attribute, so files report 0666 (or 0444), &0o111 is always 0, and no plugin is ever discovered on Windows. Executability on Windows is determined by extension via PATHEXT (.exe, .bat, .cmd, .com).

Confirmed on a Windows machine: five tests fail with "map[]" should have N item(s), but has 0 —
TestManager_discoverPlugins_{WithExecutableFiles, SkipsHiddenFiles, SkipsDirectories, MultipleExecutables, OnlyDiscoverAllowed}. They fail identically on main, so this is pre-existing and not caused by #299.

Fix: split the executability check per platform, following the existing precedent in this same package (internal/files/paths_windows_test.go, //go:build windows):

• unix: keep the 0o111 permission check
• windows: match against PATHEXT extensions
• tests for both

Found while reviewing #299 for cross-platform behavior.

[danielgaskins]

I'm happy to handle this one. I would keep the Unix permission check in a !windows helper and add a Windows helper that follows Go's os/exec.LookPath rules: case-insensitive PATHEXT, the .com, .exe, .bat, and .cmd fallback when it is unset, and extensionless configured names mapping to the matching file path.

The allowed-name filter would run against the normalized plugin name so name = "my-plugin" finds my-plugin.exe. When multiple executable extensions exist for the same name, discovery would honor their PATHEXT order.

I would add platform-specific tests covering custom and default PATHEXT, disallowed extensions, case differences, allowed filtering, extension priority, and existing Unix behavior. Does that scope match what you had in mind?