Java: avoid provider resource extraction when library already exists in onnxruntime.native.path

[TsofnatMaman]

Summary

Fixes the Java native provider loading flow so that extractProviderLibrary checks
onnxruntime.native.path before attempting extraction from classpath resources.

Previously, when a provider library was already present in onnxruntime.native.path,
the Java loader could still attempt extractFromResources(...) first, and only fall
back to the configured native path afterwards. This caused an unnecessary extraction
attempt even though the library was already available on disk.

This change updates the lookup order to:

1. Return immediately if the provider was already marked as ready
2. Check whether the provider library already exists in onnxruntime.native.path
3. Only if not found there, attempt extraction from classpath resources

Tests

Added a regression test covering the case where the requested provider library already
exists in onnxruntime.native.path.

The test verifies that:

• extractProviderLibrary(...) returns true
• extraction from resources is not attempted in that case

A small test-only hook was added to observe calls to extractFromResources(...) so the
regression can be validated directly and deterministically.

Issue

Fixes #27655

[Craigacp]

The core change is fine, but the hooks and other tricks to make a test are not ideal. It would be better to remove those hooks and the test, the logic is simple enough.

[Craigacp]

LGTM

[TsofnatMaman]

Thanks for the review, @skottmckay
Some required checks are stuck in “Expected — Waiting for status to be reported”.
Could you please trigger them?
Thanks!

[skottmckay]

/azp run Windows ARM64 QNN CI Pipeline,Windows GPU Doc Gen CI Pipeline,Win_TRT_Minimal_CUDA_Test_CI,Linux QNN CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).