[ExecuTorch] Partitioner: emit target_device CompileSpec

[shoumikhin]

What

Mirror executorch/backends/cuda/cuda_partitioner.py's pattern in TensorRTPartitioner: append a target_device="cuda:0" CompileSpec if not already present.

Why

ExecuTorch's PropagateDevicePass (auto-runs in to_executorch()) reads the target_device CompileSpec from delegates and tags their I/O TensorSpec.device. The tag is then serialized into extra_tensor_info.device_type in the .pte.

Today the tag is metadata only — ExecuTorch's default memory planner (enable_non_cpu_memory_planning=False) still allocates all tensors on CPU regardless. But once a future ExecuTorch release wires CUDA-aware memory planning + a CUDA allocator backing memory, the tag becomes load-bearing: TRT subgraph I/O will be allocated directly on CUDA, eliminating per-call host↔device staging.

This PR emits the metadata at .pte build time so users get the future fast path automatically, without needing a new torch-tensorrt release.

Pattern precedent

Direct copy of executorch/backends/cuda/cuda_partitioner.py:42-52.

Changes

py/torch_tensorrt/executorch/partitioner.py: append CompileSpec(TARGET_DEVICE_COMPILE_SPEC_KEY, b"cuda:0") to compile_specs in TensorRTPartitioner.__init__ unless the user already provided a target_device spec.

Also: defensive copy of caller-supplied compile_specs list (was aliased; now list(compile_specs) if compile_specs else []).

Notes

• No backend code change. An earlier draft of this PR added a "trust the device tag → skip cudaPointerGetAttributes syscall" fast path in TensorRTBackend::execute. That was incorrect: the tag is metadata, not a guarantee of pointer provenance. ExecuTorch's cuda_backend.cpp:498-502 documents this exact distinction. The backend continues to use cudaPointerGetAttributes as the source of truth.
• No regression: old .pte files without extra_tensor_info are still parsed as CPU by the runtime; backend's existing auto-detect path handles them unchanged.

Test plan

• Verified with a TRT-delegated .pte that extra_tensor_info.device_type=1 is emitted on delegate I/O tensors (portable runtime).
• Verified that runtime numerical outputs are unchanged (backend still stages CPU→CUDA via cudaMemcpyAsync as before).
• Caller's compile_specs list is not mutated post-construction.

[lanluo-nvidia]

Could you please raise it on top of main, no more changes to go into 2.12, I will add a release notes, stating always default cuda:0 device
Also make sure to change py/torch_tensorrt/compile.py:1245: since currently in the public ExecuTorch save path constructs TensorRTPartitioner() without any compilespecs

[shoumikhin]

Thanks @lanluo-nvidia for the review!

Rebased onto main and switched the base branch. Also added the compile.py change you asked for: _save_as_executorch now accepts a compile_specs= kwarg and forwards it to TensorRTPartitioner. So the public ExecuTorch save path gets the default target_device="cuda:0" automatically, and callers who want a different device can pass compile_specs=[CompileSpec("target_device", b"cuda:N")] to torch_tensorrt.save(...).

Docstring on save() and the unused-kwarg warning are both updated to mention compile_specs=. PTAL.