[Bug]: go.mod major-version mismatch breaks `go get` and forces insecure pseudo-versions

Describe the bug
The gpu-operator repository's go.mod declares the module as github.com/NVIDIA/gpu-operator (a v0/v1 path) even though release tags have moved to v23.x, v24.x, and beyond. Under Go's major-version suffix rule, any module at v2 or above must embed the major version in its module path (e.g. github.com/NVIDIA/gpu-operator/v24). Because this has not been done, downstream consumers cannot pin any released version with go get and are forced to reference arbitrary commits as pseudo-versions — a pattern that introduces real security and compliance risks.

To Reproduce

1. Attempt to add the latest released version as a dependency:

   go get github.com/NVIDIA/gpu-operator@v24.x.y
   

2. Observe the failure — Go cannot resolve the tag because the module path in go.mod does not carry the /v24 suffix required by semver.

3. The only working workaround is pinning a raw commit hash, which produces an unresolvable pseudo-version such as:

   github.com/NVIDIA/gpu-operator v1.8.3-0.20260527175454-2369b0586cbd
   

   (base tag v1.8.3, timestamp 20260527175454, commit 2369b0586cbd)

Expected behavior

Downstream consumers should be able to run:

go get github.com/NVIDIA/gpu-operator/v24@v24.x.y

and have Go resolve the dependency to the correct, signed release tag.