Declare Drupal 12 compatibility and turn on the next-major test lane

audit_trail declares core_version_requirement: ^11.3, and its CI configuration turns the next-major lane off with OPT_IN_TEST_NEXT_MAJOR: 0. So no evidence exists either way about Drupal 12, and every project that depends on audit_trail inherits the pin and cannot resolve a next-major lane of its own.

Measured from kessai, whose kessai_audit_trail submodule takes drupal/audit_trail ^1.0@alpha as a development dependency. Its composer (next major) job fails before installing anything:

Your requirements could not be resolved to an installable set of packages.
  - Root composer.json requires drupal/audit_trail ^1.0@alpha -> satisfiable by drupal/audit_trail[1.0.0-alpha1, ..., 1.0.0-alpha5].
  - Root composer.json requires drupal/core-recommended main-dev -> satisfiable by drupal/core-recommended[dev-main].
  - drupal/audit_trail 1.0.0-alpha5 requires drupal/core ^11.3 -> satisfiable by drupal/core[11.3.0-alpha1, ..., 11.x-dev].

Relaxing only audit_trail is not enough: the next attempt reports that audit_trail requires drupal/key ^1.18, and key pins core in turn, so both have to be allowed before the lane resolves at all.

What is actually unknown

Whether audit_trail works on Drupal 12. The Project Update Bot issue #3595431: Automated Drupal 12 compatibility fixes for audit_trail 1.x-dev carries generated deprecation fixes, but nothing has run the module own tests against Drupal 12, so those fixes are unverified and the absence of others is unproven.

Proposed steps

• Set OPT_IN_TEST_NEXT_MAJOR: 1 and run the lane. The phpstan next-major job comes first, since it reports the deprecations core will remove.
• Fix what it reports, reconciling with the generated changes in #3595431: Automated Drupal 12 compatibility fixes for audit_trail 1.x-dev rather than applying them blind.
• Widen core_version_requirement to ^11.3 || ^12 once the lane is green.
• Cut a new alpha release afterwards. Consumers pin ^1.0@alpha, which resolves to the released tags, so a widened 1.x branch alone leaves them exactly as blocked as they are now.

Until then a consumer can unblock its own lane with the lenient plugin, listing both projects, which is what kessai does in its CI variables:

_LENIENT_ALLOW_LIST: 'audit_trail,key'