Make the CUDA backend page agree with the TensorRT page

The CUDA backend page said several things that the TensorRT page, and the
code, contradict:

- It said the Python runtime allocates host memory for an unplanned output,
  so a method that keeps its outputs on the GPU could not run from Python.
  The Python runtime allocates a new device buffer for each call.
- It said a planned input fed with GPU memory makes an undefined host
  memcpy and crashes. The runtime refuses that copy and the call fails with
  NotSupported.
- It asked for a CUDA 11.x or later toolkit to run a model. The prebuilt
  packages use CUDA 13 and bring the CUDA runtime with them on Linux, a
  build from source also supports CUDA 12.6, and the toolkit is needed for
  export, where nvcc compiles the kernels. It also gave no minimum GPU,
  while the packages are built for compute capability 8.0 and newer, and it
  asked for Python 3.8+, while the package needs 3.11 to 3.15.
- It listed Windows without saying that programs for Windows are exported
  on Linux. It now links to the C++ guide section that shows how.

Author: shoumikhin

docs/source/backends/cuda/cuda-overview.md

@@ -7,24 +7,27 @@ The CUDA backend is the ExecuTorch solution for running models on NVIDIA GPUs. I
 - **Optimized GPU Execution**: Uses AOTInductor to generate highly optimized CUDA kernels for model operators
 - **Triton Kernel Support**: Leverages Triton for GEMM (General Matrix Multiply), convolution, and SDPA (Scaled Dot-Product Attention) kernels.
 - **Quantization Support**: INT4 weight quantization with tile-packed format for improved performance and reduced memory footprint
-- **Cross-Platform**: Supports both Linux and Windows platforms
+- **Cross-Platform**: Runs on Linux and Windows. Programs for Windows are exported on Linux.
 - **Multiple Model Support**: Works with various models including LLMs, vision-language models, and audio models
 
 ## Target Requirements
 
 Below are the requirements for running a CUDA-delegated ExecuTorch model:
 
-- **Hardware**: NVIDIA GPU with CUDA compute capability
-- **CUDA Toolkit**: CUDA 11.x or later (CUDA 12.x recommended)
-- **Operating System**: Linux or Windows
+- **Hardware**: NVIDIA GPU with compute capability 8.0 (Ampere) or newer
+- **CUDA**: 13 for the prebuilt packages, which bring the CUDA runtime with them on Linux. A build
+  from source also supports CUDA 12.6.
+- **Operating System**: Linux, or Windows for programs exported on Linux (see
+  [CUDA on Windows](../../using-executorch-cpp.md#cuda-on-windows))
 - **Drivers**: PyTorch-Compatible NVIDIA GPU drivers installed
 
 ## Development Requirements
 
 To develop and export models using the CUDA backend:
 
-- **Python**: Python 3.8+
+- **Python**: Python 3.11 to 3.15
 - **PyTorch**: PyTorch with CUDA support
+- **CUDA Toolkit**: export compiles kernels with `nvcc`, the CUDA compiler, so it needs a CUDA toolkit
 - **ExecuTorch**: Install ExecuTorch with CUDA backend support
 
 ## Using the CUDA Backend
@@ -142,8 +145,8 @@ exec_program = et_program.to_executorch(
         enable_non_cpu_memory_planning=True,
         # Required alongside the skips. Memory planning reserves a buffer for graph inputs by
         # default, and the runtime fills a planned input by copying the caller's memory into that
-        # buffer, which reintroduces the copy you just asked to skip. On device memory that copy is
-        # a host memcpy into a device pointer, which is undefined.
+        # buffer, which reintroduces the copy you just asked to skip. For a device tensor the
+        # runtime refuses that copy, so the call fails.
         # Outputs stay planned, so the runtime allocates them on the device and hands back a
         # pointer to its own buffer. See the note below for when to unplan them instead.
         memory_planning_pass=MemoryPlanningPass(alloc_graph_input=False),
@@ -171,23 +174,22 @@ during device-aware memory planning.
 
 **Inputs must be unplanned**, via `MemoryPlanningPass(alloc_graph_input=False)`. Without it the
 program reserves its own input buffer and the runtime copies the caller's memory into it, so the
-copy comes back at run time. On device memory that copy is a host memcpy into a device pointer,
-which is undefined, so the program crashes rather than returning a wrong answer.
+copy comes back at run time. For a device tensor the runtime refuses that copy, so the call fails
+with error `0x10` (`NotSupported`) and the log says `Error copying tensor data at input 0`.
 
-**Outputs have two valid shapes, and which one you want depends on the language.**
+**Outputs have two valid shapes.**
 
-Leave outputs planned, which is the default, when the caller cannot supply device memory itself.
-The planned buffer is allocated on the device because `enable_non_cpu_memory_planning` is on, and
-`skip_d2h_for_method_outputs` means nothing copies it back, so the result stays on the device and
-the caller receives a pointer to the runtime's own buffer. That buffer belongs to the method and is
-reused by the next execution, so read or copy the result before running again. This is the shape
-every Python caller wants, and it is what the exporters in this repository use, for example
+Leave outputs planned, which is the default, in most cases. The planned buffer is allocated on the
+device because `enable_non_cpu_memory_planning` is on, and `skip_d2h_for_method_outputs` means
+nothing copies it back, so the result stays on the device. That buffer belongs to the method and is
+reused by the next execution. A C++ caller gets a pointer to it, so read or copy the result before
+running again. From Python, `execute()` returns a copy on the GPU unless you pass
+`clone_outputs=False`. This is what the exporters in this repository use, for example
 `examples/models/gemma4_31b/export.py`.
 
-Set `alloc_graph_output=False` only when the caller supplies the output memory itself, which today
-means a C++ caller handing the runtime a device tensor through `Module::set_output`. The Python
-bindings allocate host memory for an unplanned output, so a device resident method exported this
-way cannot run from Python.
+Set `alloc_graph_output=False` when the caller should own the output memory instead. A C++ caller
+hands the runtime a device tensor through `Module::set_output`. The Python runtime allocates a new
+device buffer for each call and returns it without a copy.
 
 **Per-method selection is on the outer config, not on the flags.** Pass a dict of
 `PropagateDeviceConfig` keyed by method name: