ScriptRunner compiles verify.groovy to JDK version, not maven.compiler.release version, then fails evaluation

### Affected version

3.10.1

### Bug description

Whenever a new bytecode version is defined, m-invoker-p needs a new version of Groovy 3 that supports the new bytecode version, otherwise `verify` in the context of a `verify.groovy` script fails with the well-known unrecognized bytecode version error. This is an ancient type of problem and an old problem in m-invoker-p, and the problem is usually (always?) prevented with timely releases from the perspective of m-invoker-p.

However, in a tree of transitive dependencies, it's still possible to miss the deadline. Additionally, it means that old source code revisions become unable to run as the executing JDK evolves.

Further, it seems like this happens because **`verify.groovy` is default-compiled to target the bytecode version of the JDK version that runs m-invoker-p, instead of targeting any earlier version, perhaps in particular the `maven.compiler.release` value**.

The issue can be worked around by substituting a Groovy version that supports the relevant bytecode level, provided one exists (it always has in my encounters). I believe it cannot be worked around with conditional tests; the effect would be that no `verify.groovy` tests run at all, which obviously cannot be desirable. It cannot be worked around with toolchains, which is merely an easy mechanism to activate alternative JDKs when the bigger issue is a lack of control over available JDKs.

Start by locating ScriptRunner's compilation path for verify.groovy and how the maven.compiler.release value is exposed to it. Reproduce the failure with the affected 3.10.1 setup, then verify that verify.groovy targets the configured release and that its evaluation tests pass on a newer JDK.

Written by the indexing model from the issue text.