Fix TensorRT CUDA graph shared-lib test flake by reusing RunOptions

[Copilot]

Description

Test Linux TensorRT x64 Release failed in CApiTest.basic_cuda_graph because the third replay returned stale output after input update.
This change aligns basic_cuda_graph with the annotated CUDA graph test path by using one persistent Ort::RunOptions object across all runs.

• Failure addressed

  • onnxruntime_shared_lib_test / CApiTest.basic_cuda_graph expected updated replay output ({10, 40, 90, 160, 250, 360}) but observed initial output ({1, 4, 9, 16, 25, 36}).

• Code change

  • In onnxruntime/test/shared_lib/test_inference.cc, instantiate Ort::RunOptions run_option; once in CApiTest.basic_cuda_graph.
  • Replace per-call temporaries (Ort::RunOptions()) with the shared run_option in all three session.Run(...) invocations.

• Representative snippet

Ort::RunOptions run_option;
session.Run(run_option, binding);  // capture
session.Run(run_option, binding);  // replay
session.Run(run_option, binding);  // replay after input update

Motivation and Context

The failing TensorRT Linux Actions job was isolated to basic_cuda_graph, and the behavior diverged from the passing annotated CUDA graph path that already reuses a persistent RunOptions.
Unifying this usage removes the mismatch in graph replay setup for this test scenario and addresses the observed stale-output failure.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Scott McKay (skottmckay)]

Copilot This doesn't make sense as the RunOptions are const inputs to Run. How is using a shared instance changing the test behaviour?

Is there a different reason the data is out of sync like maybe a cudaMemcpy failed?

[Copilot]

Copilot This doesn't make sense as the RunOptions are const inputs to Run. How is using a shared instance changing the test behaviour?

Is there a different reason the data is out of sync like mayb...

You're right—reusing RunOptions doesn’t make sense here since Run takes it as const input. I reverted that in 81ebfd1 and updated CApiTest.basic_cuda_graph to assert every cudaMemcpy call succeeds so copy failures are surfaced directly instead of showing up later as stale-output mismatches.