fix: harden Windows AVX2 probe

[vamshikrishnaramasamy]

Fixes #822.

Updates the Windows AVX2 PowerShell probe used by the CLI launchers. The probe now uses the fully qualified DllImport attribute and ErrorAction Stop, making failures explicit so non-AVX2 machines are less likely to incorrectly proceed with the optimized win32-x64 binary instead of the baseline target.\n\nValidation:\n- node --check freebuff/cli/release/index.js\n- node --check cli/release/index.js\n- node --check cli/release-staging/index.js\n\nNote: I verified syntax locally on macOS, but could not run the Windows PowerShell probe directly on this machine.

[MaelllDev]

Thanks for the quick fix and for updating the documentation!

I’ll test it on my Windows 11 machine with an Intel Core i5-3570 (AVX, no AVX2) as soon as the new version is available and report back if everything works as expected.

[vamshikrishnaramasamy]

Thanks! That would be super helpful. This PR should make the launcher choose the baseline binary more reliably on non AVX2 CPUs, so your i5 3570 is exactly the kind of machine worth validating on.

[codebuff-team]

Good, focused change. Fully-qualifying DllImport as System.Runtime.InteropServices.DllImport and adding -ErrorAction Stop to Add-Type is the right way to make compile failures in the inline C# snippet explicit rather than letting $f end up $null and the subsequent $f::IsProcessorFeaturePresent(40) call produce ambiguous output that the JS wrapper could misinterpret as "has AVX2". That lines up with the failure mode described in #822 (incorrectly proceeding with the optimized binary on non-AVX2 machines).

A few things worth calling out before this gets ported:

• The change is applied identically to cli/release/index.js, cli/release-staging/index.js, and freebuff/cli/release/index.js. If these are generated from a shared source template internally, the fix should land there instead of being hand-duplicated three times — worth checking with a maintainer which is the actual source of truth.
• No Windows-side verification was possible (understandable, given the dev is on macOS), so a maintainer will need to confirm on an actual Windows box, ideally both Windows PowerShell 5.1 and PowerShell Core, since the implicit-using behavior for Add-Type -MemberDefinition can differ between them, which is presumably the root cause here.
• The failure-path behavior downstream (does throwing now cause a clean fallback to the baseline binary, or does it bubble up as an uncaught error?) isn't shown in the diff context — worth double-checking probeWindowsAvx2's caller handles the newly-explicit exception path.

Overall: right instinct, small and surgical diff, plausible root-cause reasoning. Worth a maintainer's time to verify on Windows and decide where the canonical source lives.

[MaelllDev]

Thanks! I also noticed that the bot:triaged and pr:port-candidate labels were added.

I can confirm the fix is working correctly on my side as well. I’ve been using the updated version on Windows 11 with my Intel Core i5-3570 (AVX, no AVX2), and I haven’t encountered the issue again. The launcher correctly uses the baseline binary and Freebuff starts normally.

Looks good from my side. Thanks for the quick fix