ci: add selective wheel build plumbing

[kkraus14]

Important

Stack dependency: PR 1 of 4. This is the foundation and has no PR dependency. #2465, #2466, and #2467 depend on it; merge this PR first.

Merge order: #2464 (this PR) -> #2465 -> #2466 -> #2467. All branches live in the kkraus14 fork and target upstream main, so later PR diffs are cumulative until their dependencies merge.

What

• Add default-on inputs for independently building cuda-pathfinder, cuda-bindings, cuda-core, and cuda-python.
• Add default-on inputs for producing cuda-bindings and cuda-core test fixtures.
• Hydrate unchanged wheels from an exact baseline workflow run, then republish them under the current run's artifact names.
• Gate the exact local-wheel constraint generation added by ci: constrain internal builds to exact local wheels #2510 so it runs only for selected consumer builds.
• Preserve ci: constrain internal builds to exact local wheels #2510's precise CUDA-major wheel selection, pip 25.3 setup, and separation of current- and prior-major cuda-bindings wheels.
• Preserve current Python 3.15/3.15t behavior without globally enabling prerelease resolution through PIP_PRE.

Why

The reusable build workflow needs package-level controls and artifact reuse before the top-level CI workflow can safely skip unaffected builds. The selective gates integrate with #2510's exact direct-file constraints so reused and freshly built internal wheels retain deterministic resolver precedence.

Behavior before activation

Every new input defaults to true, and this PR does not change any caller. CI therefore keeps building and preparing all packages until the orchestration PR activates selective values.

Validation

• Full pre-commit hooks for the changed workflow, including secret scanning, YAML validation, and actionlint
• Artifact producer/consumer and skipped-step review against current main
• Selective-gate review against ci: constrain internal builds to exact local wheels #2510's current- and prior-CUDA exact-wheel constraint paths

Related to #299.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[kkraus14]

/ok to test 4cd463f

[kkraus14]

/ok to test 9c7d09f

[kkraus14]

/ok to test 7658e36

[kkraus14]

/ok to test a313460b29

[kkraus14]

/ok to test a313460

[kkraus14]

/ok to test 373a954

[mdboom]

Makes sense to me as a first step of something that will be really awesome to have.

I hesitate a bit because it's at odds with the "put less logic in GHA CI config" discussion we had the other day. (It would be amazing if I could run this logic locally and say "test what needs to be tested based on my local changes"). But that's perfect is the enemy of the good -- we can always merge this approach now and refactor to something more "portable" later.

[kkraus14]

I hesitate a bit because it's at odds with the "put less logic in GHA CI config" discussion we had the other day. (It would be amazing if I could run this logic locally and say "test what needs to be tested based on my local changes"). But that's perfect is the enemy of the good -- we can always merge this approach now and refactor to something more "portable" later.

I agree and is something I've been thinking about. Writing a bunch of bash / powershell / etc. code doesn't feel like the right approach either. Something like moon (https://moonrepo.dev/moon) or bazel would probably be the right fit, but is a bit concerning from a maintainability perspective.

[github-actions]

Doc Preview CI
Preview removed because the pull request was closed or merged.