#268)

Builds on top of #265. Maven port of
getsentry/sentry-android-gradle-plugin#1350 (which itself is stacked on
the SAGP equivalent of #265,
getsentry/sentry-android-gradle-plugin#1349).

## What

Fails the build when the OpenTelemetry versions resolved for a project
are **downgraded** below what Sentry's `sentry-opentelemetry-*`
artifacts were built and tested against.

## Why

Sentry's OpenTelemetry artifacts declare the exact OpenTelemetry
versions they require. When another dependency management mechanism —
most commonly Spring Boot (via `spring-boot-starter-parent` or an
imported `spring-boot-dependencies` BOM) — forces OpenTelemetry below
those versions, it happens **silently** (the user never declares an OTel
version). Running against the mismatched versions can throw
`ClassNotFoundException` / `NoSuchMethodError` at runtime. This surfaces
the problem at build time with actionable guidance instead.

This **replaces an earlier approach that auto-installed the BOM**
(previous PR #266). In Maven a late-injected import-scope BOM is a no-op
(BOM imports are flattened during effective-model building, before
`afterProjectsRead`), and rewriting inherited `dependencyManagement` in
place is too surprising. Detecting-and-failing is the more honest
behavior — same conclusion as SAGP #1350.

## How it works

- Runs in the lifecycle participant (automatic, no execution config
needed), reusing the dependency resolution already done for
auto-install.
- Gated by a cheap check: skipped entirely unless the project uses a
`sentry-opentelemetry-*` artifact.
- Resolves each present `sentry-opentelemetry-*` artifact to determine
the OpenTelemetry versions it requires (declared dependencies + its own
dependency management), then compares against the versions actually
resolved on the project. A resolved version lower than the required
version is a downgrade.
- Only OpenTelemetry modules a `sentry-opentelemetry-*` artifact
requires are inspected, so unrelated OpenTelemetry usage is never
flagged. Unparseable versions are skipped.
- The failure message lists each downgrade and shows the exact
`<dependencyManagement>` import for `sentry-opentelemetry-bom` at the
resolved Sentry version, noting Maven's first-declaration-wins ordering
when Spring Boot is present.

## Config

Opt out with
`<skipValidateOpenTelemetryVersions>true</skipValidateOpenTelemetryVersions>`.
Adds a `SENTRY_validateOpenTelemetryVersions` telemetry tag.

## Phase / placement

Implemented in the lifecycle participant (runs before any phase,
automatically) rather than as an opt-in `validate`-phase mojo, so users
get protected by default — matching SAGP #1350's automatic, default-on
behavior.

## Open items (mirroring SAGP #1350)

- **Docs URL is a placeholder**
(`.../platforms/java/tracing/instrumentation/opentelemetry/troubleshooting/`)
and must resolve to a live page before release.
- **Default-on is a product call.** Defaulting a build-breaking check to
on will surprise existing Spring Boot users on upgrade. Either keep
default-on with a clearly-flagged behavioral-change changelog entry, or
ship opt-in first and flip later based on telemetry.

## Tests

- Unit (`OpenTelemetryVersionCheckerTest`): downgrade detection (match /
upgrade / not-resolved / alpha / unparseable), eligibility gate, and
failure-message content (mismatch line, BOM snippet, opt-out, Spring
Boot ordering note).
- Integration (`OpenTelemetryVersionCheckTestIT`): build fails on a
Spring Boot parent downgrade with the guidance message; succeeds when
not downgraded; succeeds when disabled; no-op without a Sentry
OpenTelemetry dependency.

Co-authored with Claude.

---------

Co-authored-by: Claude <[email protected]>