add cap for MKL version across all flavours to avoid solver thrashing

[h-vetinari]

The blas metapackage here handles the BLAS/LAPACK flavour globally across an end-user's environment, but from the POV of the solver, it's just another version to maximize. And if there are several contradictory possibilities on which package to choose to optimize, new MKL versions will often push the solver to ignore the flavour here, and maximize the MKL version at the expense of switching the entire blas flavour of the environment, which is counter-intuitive and undesired from the POV of the users:

- libblas                            3.9.0  25_win64_mkl           conda-forge        4MB
+ libblas                            3.9.0  25_win64_openblas      conda-forge        4MB
- libcblas                           3.9.0  25_win64_mkl           conda-forge        4MB
+ libcblas                           3.9.0  25_win64_openblas      conda-forge        4MB
- liblapack                          3.9.0  25_win64_mkl           conda-forge        4MB
+ liblapack                          3.9.0  25_win64_openblas      conda-forge        4MB

This is mainly relevant on windows (where we default to MKL), but obviously it affects all x64 architectures that want to use MKL.

So to avoid the temptation for the solver in wrongly updating MKL and inadvertently switching the flavour, add a cap for MKL across all flavours. This will help, because we're currently in just such a situation as explained above, due to conda-forge/intel_repack-feedstock#83, which is blocking #128.

We will likewise need to repodata patch this constraint into old blas builds, because otherwise the solver will just select an older build.

What this means going forward is that new MKL major versions can still be published as usual on https://github.com/conda-forge/intel_repack-feedstock, but it will actually require a PR on this feedstock to enable a new MKL major version in a way that becomes co-installable with other packages depending on the shared blas infrastructure. This is fully aligned with the fact that MKL uses a mix of SemVer and CalVer (or rather: both simultaneously), see conda-forge/intel_repack-feedstock#81.

PTAL @conda-forge/blas

CC @conda-forge/intel_repack

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/13300233007. Examine the logs at this URL for more detail.}

[hmaarrfk]

Thanks for hunting this down!

[isuruf]

Let's just use mkl-devel in host for run_exports

[h-vetinari]

Feedback addressed, PTAL. :)

[isuruf]

Thanks