CVS-167480 : Update ORT Error Codes handling during OV Import & Compilation flow

[ankitm3k]

This PR enables exceptions handling during compilation failure raising ORT_EP_FAIL Error Code & Import Flow failure raises ORT_INVALID_GRAPH Error Code.

JIRA -
https://jira.devtools.intel.com/browse/CVS-167480

[ankitm3k]

@MayureshV1 & @javier-intel please review & merge this PR too in conjunction to PR https://github.com/intel-innersource/frameworks.ai.onnxruntime.staging/pull/182

[Copilot]

Pull Request Overview

This PR implements structured error code handling for OpenVINO execution provider by encoding ORT error codes in exception messages during model import and compilation flows. The changes enable differentiation between import failures (ORT_INVALID_GRAPH) and compilation failures (ORT_EP_FAIL).

• Added error code parameter to OvExceptionBoundary template function with default ORT_EP_FAIL
• Encoded error codes as message prefix using "|message" pattern
• Updated compute function to extract and use encoded error codes from exceptions

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
onnxruntime/core/providers/openvino/ov_interface.cc	Added error code parameter to exception boundary with message encoding; specified ORT_INVALID_GRAPH for import failures
onnxruntime/core/providers/openvino/openvino_execution_provider.cc	Added error code extraction logic in compute function to parse encoded error codes from exception messages

---

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

[MayureshV1]

@ankitm3k .. Can you consider porting the goodness from the previous effort that was put in to report these error codes. This also gives us the option to report out granular errors from the lower stack whom we worked with to get it implemented.

[ankitm3k]

@ankitm3k .. Can you consider porting the goodness from the previous effort that was put in to report these error codes. This also gives us the option to report out granular errors from the lower stack whom we worked with to get it implemented.

Yes @MayureshV1 , I have also recently added all the goodness form the PR #715 from @javier-intel . We are good to merge this PR now.

[javier-intel]

It seems we're reinventing the wheel here by creating custom messages that then require parsers to work. Instead leverage the original design that created an exception type with all the needed information. That avoids the need for adding new parsers.

[ankitm3k]

It seems we're reinventing the wheel here by creating custom messages that then require parsers to work. Instead leverage the original design that created an exception type with all the needed information. That avoids the need for adding new parsers.

Well, I have rebased & amended your changes on your PR #715. lets merge & close this one in that case. PR #715 is uptodate now with latest config 1