Verify the plugin still compiles against its declared prerequisite

[slachiewicz]

Adds a CI job that compiles main and test sources against the Maven version
<prerequisites> declares, so the plugin's supported baseline is actually tested.

  baseline:
    name: Baseline (Maven 3.6.3 API)
    ...
      - run: mvn -B --no-transfer-progress -DmavenVersion=3.6.3 clean test-compile

test-compile rather than verify on purpose: API drift is a compile-time property, so
compiling both source roots is sufficient, and it avoids the cost of a second full test run.
It builds with the normal CI Maven — only the ${mavenVersion} dependency stack moves — so
the inherited requireMavenVersion (3.9) is unaffected.

clean is load-bearing. Without it the compiler reports "Nothing to compile - all classes are
up to date" against a target/ left by an earlier step, and the job passes green having
compiled nothing against the baseline.

Rebased onto master now that #1684 has landed, so the job is green. It was red before that fix,
which was the point — see #1682.

Why the existing checks missed the drift

• The verify matrix runs 3.10.0-rc-1 and 4.0.0-rc-6; 3.6.3 is never built.
• requireMavenVersion constrains the Maven that builds the project, not the API level it
  compiles against.
• A class-level linkage check (jdeps -verbose:class) reports it clean —
  MojoExecutionException exists in both versions and only the constructor differs. Catching it
  needs a member-level check, which is what compiling gives you.

Known gap, deliberately not closed here

<resolverVersion> moves independently of <mavenVersion>, and maven-resolver-api is
provided scope. So under Maven 3.6.3 the plugin runs against the resolver 1.4.1 that Maven
ships, while this job still compiles it against 1.9.25 — the same drift class, still unguarded.

Adding -DresolverVersion=1.4.1 costs nothing today: both master and #1680 compile clean
against it. Left out to keep this PR to a single change; happy to fold it in if preferred.

_{Drafted with Claude — please verify}

[slachiewicz]

Taking the first option: the fix is #1684, separately labelled so it lands in the release notes as a bug rather than under build. This job goes green once that merges; keeping it draft until then.

Checked that neither PR conflicts with #1680 — the file sets are disjoint, and #1680 compiles clean against the 3.6.3 baseline, so this job will not turn it red.