fix: TensorRT-RTX Turing (SM 7.5) capability guards and compute-capability targeting

[tp5uiuc]

What — Adds a target_compute_capabilities compilation setting, declares it on the TensorRT-RTX
builder config, and falls back to PyTorch for the ops TensorRT-RTX cannot serve on Turing.

Why — TensorRT-RTX runs on SM 7.5 and up, but its support matrix carves Turing out of several
paths: FP32 GEMMs and 3D convolutions are unsupported at compute capability 7.5, and Turing has no
bfloat16 hardware. Torch-TensorRT had no notion of this and handed those ops over anyway:

• FP32 GEMM, static shapes — createExecutionContext() returns null
• FP32 GEMM, dynamic shapes — the engine builds and runs, returning an all-zero tensor of the
  correct shape and dtype, with no exception
• 3D convolution — null execution context
• bfloat16 — segmentation fault

The dynamic-shape GEMM is the motivating case, because it fails silently.

Separately, the builder was never told which architecture it was building for. With
num_compute_capabilities == 0, Myelin looks for a precompiled module instead of JIT-ing one and
the build dies — Compatible cubin or ptx module for device target '75' not found — so on Turing
every refittable build failed.

How — Guards key off the capabilities being built for, not the build host, so an
ahead-of-time build for another architecture partitions correctly instead of baking in the build
machine. An undeclared target is resolved rather than skipped, to the current device, matching how
partitioning already resolved it — and by naming ComputeCapability.CURRENT rather than looking up
SM<major><minor>, because TensorRT-RTX names only a subset of architectures and the implicit path
must not start failing on hosts that build fine today.

The GEMM guard keys on fp32 operands only, so fp16 GEMMs accumulating in fp32 are unaffected. The
convolution guard covers forward 3D only, since transposed 3D works on Turing. bfloat16 is gated at
the partitioner rather than per-converter because the crash is not operator-specific, mirroring the
existing complex-dtype handling. Converter unit tests bypass the partitioner, so a rejected node
raises instead of falling back; those tests skip explicitly.

Testing — Confirmation sweep at the series tip, T4 (SM 7.5) and L40S (SM 8.9), driver 595.58.03,
identical stacks: T4 2668 passed / 17 failed / 226 skipped; L40S 2780 / 13 / 118; 2911 collected on
each. Declaring the capability alone closes 42 of the 91 original Turing failures. Defaulting
costs nothing off Turing: on an L40S, engines built with the default and with an explicit [(8, 9)]
are byte-identical (280148 B and 287100 B for a small conv net; 47148116 B and 24184052 B for
resnet18), with no measurable build-time difference. On the L40S there is not one status change
across all six test modules — every guard is inert off Turing.

Cost / Gotchas

• The guards switch off 105 tests on Turing, 97 of them in conversion/: the T4 runs 1981 of
  2126 tests where the L40S runs 2079. Green on Turing does not mean equally tested on Turing.
• Also clears two pre-existing lint failures in aten_ops_converters.py (an unused
  type: ignore[assignment] and a spelling the typos hook rejects). Both predate this change, but
  the file is now in the changed set so pre-commit blocks on them.

Followups — Three more capability gaps ship as stacked PRs on this branch: 3D convolution behind
the pad-folding pass, the GEMM cdist emits internally, and FP32 GEMMs reaching TensorRT-RTX through
linear and attention.

🤖 Generated with Claude Code

[tp5uiuc]

CI summary

failing check	cause
standard / test (dynamo-models, standard, l2)	test_cross_runtime_serde::test_save_cpp_load_python and ::test_save_python_load_cpp — Windows only
standard / test (dynamo-models-critical, standard, l1)	test_hf_gqa_model::test_dynamic_head_dim_with_hf_model[False-dtype0] — Tensor-likes are not close
executorch-runtime-test	OSError: libcurand.so.10
gate ×2	aggregators

Suites ran to completion: 2 failed, 150 passed, 52 skipped, 4 xpassed and 1 failed, 52 passed.

Why these are not from this PR: the same test_cross_runtime_serde pair fails identically on #4643, #4644, #4645, #4646, #4647 and #4648, whose change sets are disjoint — e.g. #4648 changes _exporter.py (the save path) and #4647 changes neither that nor anything else in common, yet both fail the same two tests with byte-identical error text. executorch-runtime-test reproduces on main nightlies and on unrelated PRs (#4638, #4642). The gate entries are aggregators of the above. test_hf_gqa_model also fails on #4645 and #4647 and has no overlap with anything this PR changes.