Add version validation to prevent silent setuptools-scm fallback versions

[rwgk]

Add import-time version validation to cuda.bindings, cuda.core, and cuda.pathfinder to detect and fail fast when setuptools-scm produces fallback versions (e.g., 0.1.dev...) due to missing git tags.

This prevents silent failures that can invalidate QA test runs and waste developer time debugging version-related issues.

Features:

• User-friendly error messages explaining the problem and how to fix it
• Opt-out mechanism via CUDA_PYTHON_ALLOW_FALLBACK_VERSIONING=1
• Consistent implementation across all three packages with sync reminder comments

The validation checks that major.minor > 0.1, which catches common fallback versions while allowing legitimate early development versions.

[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.

[leofang]

Summarizing my understanding from the meeting (I could be missing something, since we discussed a lot 😅):

• We'd prefer something like python -m numba --sysinfo or python -c "import cupy; cupy.show_config()" that can be opted in to report system/venv states, instead of adding something to __init__.py that requires opt-out
• From Python packaging perspective the added check is duplicating the responsibility of a package manager, which is very uncommon in the Python land and not scalable if we ever add more dependencies
• The fact that in-development cuda-bindings was uninstalled when installing in-development cuda-core, was because --no-build-isolation was not passed to pip. For testing against ToT we should always avoid creating a build isolation env which can install core dependencies from public PyPI.
• We should find a mechanism (@kkraus14 pointed out offline that there's fallback_version) for setuptools-scm to have a fallback, when the source code is detached from git for whatever reason, instead of generating a dummy 0.1-dev.xxxxx version string.

My take is we should close or rewrite this PR in a different approach. WDYT @rwgk @mdboom?