Build Windows ARM64 CI statically

[mpwaser]

Summary

This switches the Windows ARM64 CI job to build static OpenBLAS.

After #5899, CI started running the real openblas_utest_ext binary. On windows-11-arm, the failures appear limited to xerbla_* extension tests. The shared DLL build does not appear to use the test executable's xerbla override, so the tests report the error as missed even though OpenBLAS prints the invalid-parameter message.

Building static avoids that Windows DLL symbol-resolution issue and keeps the extension tests enabled. The earlier diagnostic LastTest.log dump is removed; the workflow runs plain ctest again.

docs/ci.md now records the Windows ARM64 job as static and notes the openblas_utest_ext/xerbla test reason.

Validation

• git diff --check
• Windows ARM64 CI must validate this on GitHub Actions.

[martin-frbg]

most likely something already addressed by #5898 - I'm running a WoA build locally now

[mpwaser]

Ok, I'll hold off on further changes/investigations here until your local WoA result.

[martin-frbg]

Curious - both NEOVERSEN1 and ARMV8 builds pass locally (on Snapdragon X Elite). Not quite sure what to make of the absolute carnage in the CI output, looks like memory corruption or ABI mismatch with all the parameter errors from the level 2&3 BLAS and CBLAS jobs.

[mpwaser]

Curious indeed. The runner failure appears limited to xerbla_* extension tests, possibly because the shared OpenBLAS DLL is not using the test executable’s xerbla override.

[martin-frbg]

Yes, that appears to be the problem - all works fine with a static build, but with a shared library some tests randomly call the "serious" version of XERBLA instead of the special one overloaded for the tests. ISTR Reference-LAPACK encountering similar problems on other platforms, maybe the changed procedure for creating shared libraries with custom symbol pre/postfixes has broken a fragile constellation that used to favor the "correct" xerbla

[mpwaser]

I see two options, adding an explicit test-only XERBLA callback in the library or skipping xerbla tests on these WoA runners.

[martin-frbg]

A third option would be to switch the CI job to building a static library

[mpwaser]

Yes, that is reasonable and not as invasive as an explicit callback