[FEA] cuda.core: support nvJitLink partial/incremental linking (CUDA 13.2)

[leofang]

Summary

nvJitLink 13.2 added its single new option in the entire 12.8 → 13.3 window: -r — "Do
relocatable (or incremental) link, producing another relocatable object" (13.2+ docs).

LinkerOptions has no counterpart today
(fields end at no_cache).
The legacy driver-JIT fallback cannot support it and should raise, following the
split_compile precedent;
CTK-version gating per #337.

Underlying C APIs to cover

The -r link option on nvJitLinkCreate (string option; no new binding symbols involved).

Design sketch (draft — needs design-meeting review)

Important

Starting point only, not a settled design — review in the cuda.core design meeting.

opts = LinkerOptions(arch="sm_100", relocatable=True)   # emits "-r"; name TBD
lnk = Linker(a_ltoir, b_ltoir, options=opts)
obj = lnk.link("cubin")                                 # relocatable object out
final = Linker(obj, c_ltoir, options=LinkerOptions(arch="sm_100")).link("cubin")

Open questions for the meeting:

1. What ObjectCode code type does a relocatable-link result map to ("object"? new kind?),
   and what does Linker.link()'s target_type argument accept in -r mode?
2. Round-tripping: accepting a relocatable result as input to another Linker (incremental
   chains) — anything needed beyond passing it through?
3. Interaction with link_time_optimization / -lto mode.

References

• nvJitLink docs (supported link options): https://docs.nvidia.com/cuda/nvjitlink/index.html
• Found during the CUDA 12.8 → 13.3 bindings vs. cuda.core gap sweep (2026-07-14)

-- Leo's bot