[Bug] sglang-kernel wheels omit required PyTorch ABI dependency metadata

## Problem

`sglang-kernel` is compiled against a specific PyTorch C++ ABI, but the generated wheel declares no runtime dependency on `torch`. This allows pip/uv to resolve an ABI-incompatible package combination that fails immediately at import time.

This was first reported against the published artifacts in sgl-project/whl#27. The build configuration that generates the metadata is maintained here:

```toml
# python/sglang/kernels/aot/pyproject.toml
[build-system]
requires = [
  "scikit-build-core>=0.10",
  "torch>=2.8.0",
  "wheel",
]

[project]
dependencies = []
```

Current `main` documents and builds the CUDA wheels with Torch 2.13.0, but neither the runtime metadata nor the isolated-build requirement enforces that ABI version.

## Reproduction

A project with the following otherwise valid dependency constraints can resolve `sglang-kernel==0.4.6.post1` alongside Torch 2.11:

```text
torch==2.11.0
sglang-kernel>=0.4.5,<0.5
```

Importing the extension then fails with an unresolved PyTorch symbol because `0.4.6.post1` was built for Torch 2.13:

```text
ImportError: common_ops.abi3.so: undefined symbol: _ZN5torch7Library4_defE...
```

The missing metadata can be verified directly:

```python
from importlib.metadata import distribution

print(distribution("sglang-kernel").metadata.get_all("Requires-Dist"))
```

Output:

```text
None
```

## Published ABI mapping

| sglang-kernel | Required Torch |
|---|---|
| 0.4.0 - 0.4.1.post1 | 2.9.1 |
| 0.4.2 - 0.4.6 | 2.11.0 |
| 0.4.6.post1 | 2.13.0 |

## Expected behavior

Future CUDA wheels should declare the exact Torch ABI version used to build them, for example on current `main`:

```toml
[build-system]
requires = ["torch==2.13.0", ...]

[project]
dependencies = ["torch==2.13.0"]
```

This would make isolated source builds and installed wheel metadata agree, allowing standard resolvers to reject or backtrack from incompatible combinations.

CPU, ROCm, and MUSA packages may require separate version declarations because they use different build configurations; this issue's observed failure and proposed initial fix concern the CUDA wheel generated from `python/sglang/kernels/aot/pyproject.toml`.

## Environment where the mismatch was observed

```text
OS: Linux x86_64, glibc 2.35
Python: 3.12
Torch: 2.11.0+cu130
CUDA: 13.0
Incompatible sglang-kernel selected by resolver: 0.4.6.post1
```

[]