Add check for pre-release generated content

[mdboom]

Now that our generator behaves differently, this is an extra check for pre-release content.

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-2373/
https://nvidia.github.io/cuda-python/pr-preview/pr-2373/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-2373/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-2373/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[Andy-Jost]

This check can silently miss pre-release content:

1. _VERSION_RE only recognizes generated across versions from … to …. Sealed files such as nvrtc.pyx use generated with version 13.3.0, so regenerating them with 13.4 would pass unnoticed.
2. When a generated marker exists but the version header is unrecognized, the script silently succeeds. It should fail closed so future header-format changes cannot bypass the check.

Could we support both current header formats and add focused tests for each, plus the unrecognized-header case?

[rwgk]

@mdboom I looked more closely, I believe these are the only essential changes in scope for this PR:

• Parse both current header formats:
  • generated across versions from ... to X.Y.Z
  • generated with version X.Y.Z

The second format is used by six files: driver, runtime, and nvrtc, each as .pyx and .pxd. (This is also exactly Andy’s first point, and what I shared earlier offline.)

• For all sealed files, ensure that the check fails if version information cannot be determined with certainty, unless it is fully understood why the version information is missing. Concretely, currently there are 69 sealed files: 59 multi-version, 6 single-version, and 4 with no CTK metadata:
  • cuda_bindings/cuda/bindings/_internal/_fast_enum.py:5
  • cuda_bindings/docs/source/module/driver.rst:4
  • cuda_bindings/docs/source/module/nvrtc.rst:4
  • cuda_bindings/docs/source/module/runtime.rst:4

If it's not easy to add CTK metadata to those files, it would seem OK to explicitly exempt them, but to reject every other sealed file with zero, multiple, or unrecognized version headers. That accommodates the status quo while also ensuring that future generator-format drift fails loudly. — I believe this is also exactly Andy's second point.