[Plugin WebGPU EP] Fix API initialization error handling

[edgchen1]

Description

This pull request improves error handling in the CreateEpFactories function in onnxruntime/core/providers/webgpu/ep/api.cc.

The main enhancement is the addition of a more conservative mechanism for creating OrtStatus objects when exceptions occur during API initialization.

The existing code was attempting to create a C++ API Ort::Status instance even if the API was not initialized successfully.

Motivation and Context

Fix crash that was hiding underlying error message.

[Copilot]

Pull request overview

This PR hardens initialization-time error handling for the WebGPU Plugin EP entrypoint (CreateEpFactories) so failures during onnxruntime::ep::ApiInit() return a usable OrtStatus instead of crashing/hiding the underlying error.

Changes:

• Adds a pre-init try/catch around onnxruntime::ep::ApiInit() with a conservative OrtStatus construction path.
• Falls back to printing an error and aborting if OrtStatus cannot be created.
• Adds <cstdio>/<cstdlib> includes to support the fallback path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[skottmckay]

The ORT API is meant to always remain backwards compatible so I don't think this is an 'assumption' as it should be a guarantee.

[edgchen1]

this comment does allow for the possibility of the API struct changing in a non-backwards compatible way. it hasn't, yet.

onnxruntime/onnxruntime/core/session/onnxruntime_c_api.cc

Lines 4221 to 4258 in c7c99ce

	/* Rules on how to add a new Ort API version
	In general, NEVER remove or rearrange the members in this structure unless a new version is being created. The
	goal is for newer shared libraries of the Onnx Runtime to work with binaries targeting the previous versions.
	In order to do that we need to ensure older binaries get the older interfaces they are expecting.
	If the next version of the OrtApi only adds members, new members can be added at the end of the OrtApi structure
	without breaking anything. In this case, rename the ort_api_# structure in a way that shows the range of versions
	it supports, for example 'ort_api_1_to_2', and then GetApi can return the same structure for a range of versions.
	If methods need to be removed or rearranged, then make a copy of the OrtApi structure and name it 'OrtApi#to#'.
	The latest Api should always be named just OrtApi. Then make a copy of the latest ort_api_* structure below and
	name it ort_api_# to match the latest version number supported, you'll need to be sure the structure types match
	the API they're for (the compiler should complain if this isn't correct).
	If there is no desire to have the headers still expose the older APIs (clutter, documentation, etc) then the
	definition should be moved to a file included by this file so that it's still defined here for binary compatibility
	but isn't visible in public headers.
	So for example, if we wanted to just add some new members to the ort_api_1_to_2, we'd take the following steps:
	In include\onnxruntime\core\session\onnxruntime_c_api.h we'd just add the members to the end of the structure
	In this file, we'd correspondingly add the member values to the end of the ort_api_1_to_2 structure, and also rename
	it to ort_api_1_to_3.
	Then in GetApi we'd make it return ort_api_1_to_3 for versions 1 through 3.
	Second example, if we wanted to add and remove some members, we'd do this:
	In include\onnxruntime\core\session\onnxruntime_c_api.h we'd make a copy of the OrtApi structure and name the
	old one OrtApi1to2. In the new OrtApi we'd add or remove any members that we desire.
	In this file, we'd create a new copy of ort_api_1_to_2 called ort_api_3 and make the corresponding changes that were
	made to the new OrtApi.
	In GetApi we now make it return ort_api_3 for version 3.
	*/

[edgchen1]

added a static_assert to enforce this