refactor: conda build command on GHA workflows

[swap357]

conda 26.3.1 removed use of conda executable (conda-build) with subcommands (conda build) -

Conda no longer discovers subcommands by scanning conda-* executables on PATH when building the CLI (prefer the plugin system).

https://conda.org/blog/2026-04-06-march-releases/#changes-in-conda-26302631

This PR corrects the usage on conda builder GHA workflows to use executable directly conda-build.

[esc]

Windows seems to be failing because:

======================================================================
FAIL: test_conda_build (llvmlite.tests.test_binding.TestBuild)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Miniconda\envs\test\conda-bld\llvmlite_1777445991762\_test_env\lib\site-packages\llvmlite\tests\test_binding.py", line 3147, in test_conda_build
    self.assertEqual(info['llvm_assertions_state'], "on")
AssertionError: 'off' != 'on'
- off
+ on

Looking at the build job, I believe it seems to be getting the wrong llvmdev:

    defaults/win-64::llvmdev-20.1.8-h48dad37_1

[esc]

I pushed an experimental commit here to try to fix this: 97bb7ca

[esc]

I pushed an experimental commit here to try to fix this: 97bb7ca

Oh, I was mistaken --channel-priority strict doesn't exist for conda-build.

[esc]

Trying to use conda config instead on: 6c93df2

[swap357]

Trying to use conda config instead on: 6c93df2

Thanks, @esc. conda config seems to be working, llvmlite build' using correct channel for llvmdev now-
numba/label/dev/linux-64::llvmdev-20.1.8-hf4eb1c0_0

[esc]

Trying to use conda config instead on: 6c93df2

Thanks, @esc. conda config seems to be working, llvmlite build' using correct channel for llvmdev now- numba/label/dev/linux-64::llvmdev-20.1.8-hf4eb1c0_0

@swap357 many thanks for confirming, now needs a third set of eyes, since both of us have added commits here. Labelled accordingly.

[esc]

Note for the second reviewer:

The channel priority had to be configured to be strict. At the time of running the following packages were present:

esc@artemis [base] [llvmlite:refactor_conda_build_command:★★★] ~/git/llvmlite conda search -c numba/label/dev llvmdev --subdir win-64 | grep 20.1.8
llvmdev                       20.1.8      h3aa9ab2_0  pkgs/main
llvmdev                       20.1.8      h48dad37_1  pkgs/main
llvmdev                       20.1.8      h659f713_0  numba/label/dev

This meant that 20.1.8 h48dad37_1 was installed from pkgs/main over 20.1.8 h659f713_0 from numba/label/dev as the former had the same version but a higher build number (1 over 0) and as a result llvmlite was built againt the wrong llvmdev (the one from pkgs/main doesn't have assertions enabled, which lead to the test failure:

======================================================================
FAIL: test_conda_build (llvmlite.tests.test_binding.TestBuild)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Miniconda\envs\test\conda-bld\llvmlite_1777445991762\_test_env\lib\site-packages\llvmlite\tests\test_binding.py", line 3147, in test_conda_build
    self.assertEqual(info['llvm_assertions_state'], "on")
AssertionError: 'off' != 'on'
- off
+ on

Using the config option conda config --set channel_priority strict enforces strict channel priority, such that the correct llvmdev from the correct channel is installed.

[stuartarchibald]

Thanks for the patch. The changes seem reasonable to fix the described problem. Side-note: the strict channel priority should probably always have been there to prevent conda-build using an llvmdev build from anywhere other than the channel prescribed in ${LLVMDEV_CHANNEL}. The llvmlite test suite is correctly failing because it "knows" about Numba channel builds of llvmdev always having assertions enabled in contrast to packages from main that do not.