executorch: derive the TensorRT delegate target_device from the engine's real device index

[shoumikhin]

What

TensorRTPartitioner hardcoded CompileSpec("target_device", b"cuda:0") for every partition, so an engine built for cuda:N shipped a .pte whose delegate-boundary tensors were labeled cuda:0. ExecuTorch's PropagateDevicePass serializes that into extra_tensor_info.device_type/device_index.

This derives target_device per export from the engine's real device index, reusing the backend's own _get_engine_info_from_edge_program + _parse_device_id so the index cannot drift from the runtime blob. It falls back to cuda:0 when the program does not have exactly one engine node (multiple TRT partitions) or the index is unreadable; per-partition multi-GPU labeling is left to a follow-up. An explicit caller-provided target_device is used verbatim, unchanged.

It also documents that target_device is AOT-only metadata (the runtime selects the GPU from the engine blob).

Why now

The runtime already runs on the correct GPU (it reads the engine blob's device_id), so this is a latent metadata bug today. ExecuTorch is moving device-aware memory planning toward the default, and that planning reads device_index to place buffers; this makes the metadata correct before it becomes load-bearing.

Risk

Low. The common single-GPU cuda:0 export is byte-identical (the derived value is still cuda:0); the only behavior change is that a single-engine non-zero-GPU export now labels the GPU the engine was actually built for. Any extraction failure falls back to the previous cuda:0. The explicit-override path is untouched.

Test plan

• Single-engine export on cuda:0: .pte unchanged.
• Single-engine export on a non-zero GPU: delegate-boundary tensors record that device index.
• Explicit CompileSpec("target_device", b"cuda:3"): used verbatim for every partition.
• Fallback: a program without exactly one engine node yields cuda:0.

Draft for review; pairs with the runtime PR #4328 and a device-memory-planning readiness test to follow.