fdfd: on GitHub's Windows runners, faer's LU of a 41k-unknown 3D strip leaves a residual of 1.6, and the 3D direct solve fails

[tachsin]

Seen on #153's CI (windows-latest, run 37288649449). bench::export::system("strip-24") (the strip with ports, 24³ cells, 41 472 unknowns), solved by Solver3d::solve_system:

the factorization left a residual of 1.5682576233890573e0, and QMR on it failed: no convergence to 6.37650335688448e-13 in 1000 iterations (the residual is at 1.942927776110285e-12)

On our machine (Windows 11, Core Ultra 7 265K) and on the Linux and macOS runners the same factors leave round-off. #82 found residuals of 1e-2 to 1e-1 on that runner on smaller 3D matrices, which QMR preconditioned by the factors repairs; here the factors are worse than useless as factors (1.6) and QMR stalls a factor of three above its target. The 2D slab's factors (149 600 unknowns, COLAMD) were also off there (the raw residual above 1e-10).

So on some Windows machines a 3D direct solve of a realistic size is an error (never a wrong field, by #82's guard). To find out:

• whether it follows the CPU (the runners' Xeon / EPYC, AVX-512) or Windows itself: the same test on a Windows runner with RAYON_NUM_THREADS=1, and with faer's SIMD dispatch limited;
• whether nested dissection (perf(fdfd): the 3D direct solver orders its LU by nested dissection, twice as fast as COLAMD at 40³ cells #147) made it worse than COLAMD did;
• whether the stall is QMR's target being out of reach (1e-12 relative, near round-off for this conditioning) rather than the preconditioner.

The exporter's two tests skip on Windows until this is settled.