chore(deps): add the shipped x86_64 Linux CUDA target to deny.toml graph targets

## Summary

`deny.toml` restricts dependency resolution to two targets, and its comment claims they are "the release targets per `.github/workflows/release.yml`". The release workflow ships a third target, x86_64 Linux CUDA, whose target-specific transitive dependencies cargo-deny therefore never checks for licenses or advisories.

## Background

The `[graph] targets` array lists only `aarch64-apple-darwin` and `aarch64-unknown-linux-gnu`, but the release workflow has a `build-linux-x86_64-cuda` job that publishes `mlxcel-linux-x86_64-cuda13` and `mlxcel-server-linux-x86_64-cuda13`, and exposes `linux-x86_64` as a dispatch target. Any dependency pulled in only under that triple is outside cargo-deny's view today.

## Proposed Solution

Add `x86_64-unknown-linux-gnu` to the `targets` array and update the comment to match the workflow. `cargo deny check` (already part of the PR checklist) verifies immediately; if the wider graph surfaces a new license or advisory finding, that finding is the point of the change and should be resolved in the same PR.

## Implementation Notes

- `deny.toml:8-11` lists `aarch64-apple-darwin` and `aarch64-unknown-linux-gnu` with the comment naming those as the release targets.
- `.github/workflows/release.yml:737` defines `build-linux-x86_64-cuda`; `:767-768` set the `mlxcel-linux-x86_64-cuda13` / `mlxcel-server-linux-x86_64-cuda13` asset names; `:21` exposes `linux-x86_64` as a dispatch target.

## Acceptance Criteria

- [ ] `deny.toml` targets cover all three shipped targets and the comment matches the workflow
- [ ] `cargo deny check` passes (or its new findings are resolved in the same PR)

---

## Original Suggestion

### Title: chore(deps): deny.toml graph targets omit the shipped x86_64 Linux CUDA release target

`deny.toml` restricts dependency resolution to two targets and its comment claims they are "the release targets per `.github/workflows/release.yml`" — but the release workflow ships a third target, x86_64 Linux CUDA, whose target-specific transitive dependencies cargo-deny therefore never checks for licenses or advisories.

## Evidence

- `deny.toml:5-11` — `[graph] targets` lists only `aarch64-apple-darwin` and `aarch64-unknown-linux-gnu`, with the comment "macOS Apple Silicon (Metal) + Linux aarch64 CUDA (gb10, gh200) are the release targets per `.github/workflows/release.yml`"
- `.github/workflows/release.yml:737-768` — the `build-linux-x86_64-cuda` job publishes `mlxcel-linux-x86_64-cuda13` / `mlxcel-server-linux-x86_64-cuda13`; `:21` exposes `linux-x86_64` as a dispatch target

## Suggested fix

Add `x86_64-unknown-linux-gnu` to the targets array and update the comment. `cargo deny check` (already part of the PR checklist) verifies immediately; if the wider graph surfaces a new license/advisory finding, that finding is the point.

## Acceptance criteria

- [ ] `deny.toml` targets cover all three shipped targets and the comment matches the workflow
- [ ] `cargo deny check` passes (or its new findings are resolved in the same PR)

Start with the [graph] targets array and comment in deny.toml:8-11, then compare it with the release targets in .github/workflows/release.yml, especially the dispatch target at line 21 and the CUDA job around lines 737-768. Add the shipped x86_64 Linux CUDA target, update the comment, and run cargo deny check; done means all three targets are covered and the check passes or its findings are resolved.

Written by the indexing model from the issue text.