Describe the bug

When resolving the latest version of an existing metadata entry, the workflow resolves it based on sorting the test directories for that library and picking out the latest there. This completely ignores the latest field of specific metadata entries and creates problems when we match multiple metadata files to the same tests.

For example:

[
  {
    "latest" : true,
    "module" : "org.flywaydb:flyway-sqlserver",
    "metadata-version" : "10.13.0",
    "test-version": "10.10.0",
    "tested-versions" : [
      "10.13.0"
    ]
  },
  {
    "module" : "org.flywaydb:flyway-sqlserver",
    "metadata-version" : "10.10.0",
    "tested-versions" : [
      "10.10.0",
      "10.11.0",
      "10.11.1",
      "10.12.0",
      // new version will be added here
    ]
  }
]

new versions will be added to the older metadata entry here, as the newer 10.13.0 metadata is matched to the 10.10.0 tests.

Steps to reproduce

Run the `verify-new-library-version-compatibility.yml` workflow.

Expected behavior

We should parse the index.json file to resolve the latest metadata version and ONLY fallback to the old parsing ways if there is no latest tag in the index file.

Logs and error messages

No logs.

Reproducer (optional)

No response

Additional context

No response

GraalVM version

GraalVM 25.0.2

Operating system

Linux

CPU architecture

AMD64 (x86-64)