fix: isolate incompatible OpenTelemetry API linkage failures

[zhongkechen]

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Description

Fixes #763. An older visible OpenTelemetry API can lack GlobalOpenTelemetry.isSet() or getOrNoop(). The resulting NoSuchMethodError previously escaped plugin dispatch and failed the customer invocation. The plugin now checks those APIs before global-provider binding and reports incompatible dependencies without installing a no-op global. Runtime hook dispatch also isolates LinkageError, so healthy plugins and the handler continue.

This is an independently mergeable 2.x fix for work item 7. Public APIs, constructors, instance lifetimes, dependency versions, and provider configuration validation are unchanged. Fatal JVM errors and ThreadDeath retain their existing propagation behavior. Align incompatible dependencies to restore telemetry; containment does not make an unsupported API export spans.

Merge this PR into main first. The separate major factory migration in #782 is stacked on this branch; after this PR merges, update #782 from main and retarget it to main. Do not merge #782 into this 2.x branch.

The CI callers preserve their existing serial shared-resource groups and retain pending runs. Java 17 Build now runs a required installed-artifact compatibility matrix; dependency-resolution and probe failures fail CI rather than skipping coverage.

Validation

• Final integrated Java 17 mvn -B clean verify: 2,171 tests, 31 existing skips, zero failures/errors, including main's CodeBuild and test-environment changes.
• Regression controls on the unfixed baseline reproduced 28 hook-containment failures and two global-provider linkage errors. Focused coverage checks all seven hooks, original fatal identity, healthy-plugin continuation, and suspension/resume without repeating a completed step.
• Installed-artifact matrix: 16/16 passed. Uses actual released core/plugin/testing SDK 2.2.1, candidate core/plugin jars, API/context 1.49.0 and 1.66.0, and both views. The old/old + 1.49 cases reproduce the exact customer failure; the fixed combinations preserve handler execution. It checks real ServiceLoader discovery, unchanged instance lifetime, late global registration, compatible Workflow export, and selected jar provenance.
• Actual released OpenTelemetry Java agent 2.32.0, Corretto 17, plugin jar loaded as the agent extension: 16/16 local cases passed across the same core/plugin/API/view combinations. The agent exported a control span; compatible API 1.66 exported Workflow spans. Older API cases preserved the handler or reproduced the expected old/old failure. This separate probe neither resets the global provider nor injects the installed-extension marker. It validates this exact agent setup, not every ADOT/Lambda layer version.
• PluginRunner public signatures match the 2.x main baseline. No production POM or dependency-floor changes.

Checklist

• Final integrated local build and regression controls passed
• Required released/current artifact matrix added to CI
• Actual released Java-agent verification completed
• Current-head CI and actual AI review completed; valid findings addressed

[github-actions]

Codex AI review

No actionable findings. Residual risk: runtime compatibility and CI workflow behavior were assessed statically and not executed, per review constraints.

Reviewed commit f4e4e1db81c6fb0fbbaf25815d73757abf3fda7c. Workflow run