Four independent build and packaging issues in the CUDA backend and wheel

These came up while working on the wheel's C++ components. None are caused by that
work, and each reproduces independently, so they are worth separate attention
rather than being folded into an unrelated change.

A CUDA build with default settings does not compile

backends/cuda/runtime/shims/int4_plain_mm.cuh:250 uses __dp4a, which requires
compute capability 6.1 or newer. Nothing in the build sets a default
CMAKE_CUDA_ARCHITECTURES, so a plain CUDA build picks whatever the toolkit
defaults to and fails with:

error: identifier "__dp4a" is undefined

Passing an explicit architecture works around it, for example 90 on a datacenter
GPU or 110 on Jetson Thor. A sensible default in the build, or a guard around the
intrinsic with a portable fallback, would let a CUDA build work out of the box.

The CUDA backend requires a newer CMake than the project declares

The repository root declares:

cmake_minimum_required(VERSION 3.24)

while backends/cuda/CMakeLists.txt:17 declares:

cmake_minimum_required(VERSION 3.29)

Any environment with a CMake between those two versions can configure the project
but not a CUDA build. On a stock Ubuntu 24.04 image, which ships CMake 3.28, this
fails with CMake 3.29 or higher is required. Either the root floor should rise or
the CUDA backend should work at the declared minimum.

The data loader extension carries a second copy of the operator table

extension/pybindings/data_loader links the static core, so the shipped module
defines the operator registration symbols itself:

nm -DC data_loader...so | grep register_kernels   -> 1 definition

The module only exposes a pybind type and calls into no runtime symbols at all
(nm reports zero undefined ExecuTorch symbols), so the static core brings in a
duplicate registry for no benefit. It also adds a couple hundred kilobytes to the
wheel. This predates the shared-runtime work; the module linked the same way
before.

The manylinux baseline is inconsistent for aarch64

The builder image and the auditwheel repair target do not agree on one manylinux
baseline: the image is built against manylinux_2_39 while repair requests
2_28. Publishing aarch64 wheels should settle on a single baseline first,
otherwise the tag a wheel claims and the glibc it was actually built against can
diverge.

cc @larryliu0820 @GregoryComer @Gasoonjia @digantdesai

Treat the report as four independent investigations. Start with backends/cuda/runtime/shims/int4_plain_mm.cuh, the root CMakeLists.txt, backends/cuda/CMakeLists.txt, and extension/pybindings/data_loader; reproduce the default CUDA configure/build and inspect the module with nm. Then locate the manylinux builder and auditwheel settings, and consider each item done only after its targeted build or wheel validation passes with a consistent configuration.