Plugins built against pre-Apache org.grails coordinates fail on Grails 8 with an empty-version resolution error

### Summary

Plugins published against the **pre-Apache `org.grails` coordinates** cannot be consumed by a Grails 8 application, and the failure is reported as a resolution error with an **empty version**, which points at nothing actionable:

```
> Could not find org.grails:grails-core:.
Required by:
root project 'seedme' > com.bertramlabs.plugins:seed-me:7.0.0
```

This is not a regression in Grails 8 behaviour - those artifacts genuinely do not exist under the new group. But it is a direct consequence of the `org.grails` to `org.apache.grails` rename, it affects a large class of plugins including ones the community has explicitly asked for, and today there is nothing in the error, the BOM, or the upgrade guide that tells a user what actually happened or what to do.

Found while working through the plugins requested in #15044 against `8.0.0-M5`.

### Grails Version

8.0.0-M5

### Why the version is empty

These plugins do declare versions - indirectly. `seed-me-7.0.0.pom` lists its Grails dependencies with no version:

```xml

org.grails
grails-core
runtime
...

```

and supplies the versions by importing the **old group's** BOM:

```xml

org.grails
grails-bom
7.0.0-M1
import

```

So this plugin **was** built for Grails 7 - just against `org.grails:grails-bom:7.0.0-M1`, published before the GA move to `org.apache.grails:grails-bom`. When a Grails 8 app consumes it, nothing manages `org.grails:*` any more, the version resolves to empty, and the build fails with the message above.

### Affected plugins observed

All of the following fail this way on 8.0.0-M5, each with `Could not find org.grails::` and an empty version:

| Plugin | Missing coordinates |
|---|---|
| `com.bertramlabs.plugins:seed-me:7.0.0` (requested in #15044) | `grails-core`, `grails-web-boot`, `grails-dependencies`, `grails-plugin-domain-class` |
| `com.bertramlabs.plugins:grails-force-ssl:7.0.0` (requested in #15044) | `grails-web-boot`, `grails-dependencies` |
| `io.github.gpc:asynchronous-mail:3.1.2` (requested in #15044) | old `org.grails.plugins:mail` line |
| `org.grails.plugins:spring-security-core:7.0.0-M3` | `grails-datastore-core`, `grails-datastore-gorm`, `grails-events-transform`, `grails-plugin-mimetypes`, `grails-web-common`, `grails-web-url-mappings`, `org.grails.plugins:async` |
| `org.grails.plugins:mongodb:9.0.0-M3` | `grails-datastore-core`, `grails-datastore-gorm`, `grails-datastore-gorm-support` |

Two of these (`seed-me`, `grails-force-ssl`) are plugins users specifically asked for in the volunteer discussion, so this is the first wall those users hit.

### Expected Behaviour

Either the legacy coordinates keep resolving to their Apache equivalents, or the build fails with a message that names the real problem, for example:

```
Plugin com.bertramlabs.plugins:seed-me:7.0.0 depends on the pre-Apache 'org.grails' coordinates
(org.grails:grails-core), which are not published for Grails 8. This plugin needs to be rebuilt
against org.apache.grails. See .
```

### Actual Behaviour

`Could not find org.grails:grails-core:` with an empty version and no indication that a group rename is the cause.

### Suggested resolution

In rough order of increasing effort:

1. **Diagnostic only.** Detect a resolution failure for a `org.grails:*` coordinate with an unresolved version and rewrite the message to explain the rename and point at the upgrade guide. The Grails Gradle plugin already detects this exact condition today in a related path - it emits a graceful warning during CLI companion probing:

```
Could not fully resolve CLI companion probe dependencies for project seedme; ...
Cause: Could not find org.grails:grails-core:.
```

so the detection point largely exists already.

2. **Document it.** Add a short section to the Grails 8 upgrade guide's plugin-compatibility notes describing this failure shape, since the error text is not searchable in any useful way.

3. **Compatibility shim.** Provide opt-in alignment from the legacy `org.grails:*` coordinates to their `org.apache.grails:*` equivalents, via Gradle module replacement / component metadata rules shipped by the Grails Gradle plugin (or relocation metadata). This would be in the same spirit as `legacyCommandSupport` in #16011 and the proposed `grails.legacy.holdersDuringDoWithSpring` in #16101 - off by default, opt-in for migration, and it would let a number of otherwise-abandoned plugins keep working while their maintainers catch up.

Option 3 needs care: the renamed modules are not always 1:1 (for example `grails-plugin-domain-class` to `grails-domain-class`, `grails-plugin-mimetypes` to `grails-mimetypes`), and a Grails 7-era jar may not be binary compatible with Grails 8 even once it resolves. Options 1 and 2 are safe regardless and would remove most of the confusion on their own.

### Notes

Part of a broader compatibility sweep of released Grails 7 plugins against 8.0.0-M5, alongside #16122, #16123, and #16124. Unlike those three, this one is not a behavioural regression - it is a discoverability and migration-path gap created by the group rename.

Start at the Grails Gradle plugin's existing CLI companion probe dependency-resolution path, where the payload says this condition is detected, and read the Grails 8 upgrade guide's plugin-compatibility notes. Decide whether the scope is diagnostic messaging, documentation, or an opt-in compatibility shim; done means the selected path explains the pre-Apache coordinates and gives migration guidance, with affected plugin cases covered.

Written by the indexing model from the issue text.