Close library requests whose artifact cannot be resolved

[kimeta]

Closes #9139

What this does

Requests for artifacts that no configured repository serves currently flow all the way into the agent workflows, which discover the problem the expensive way. #7767, #7768 and #7769 each burned three agent runs across three different bots before landing in human-intervention, every one of them rediscovering the same 404 from Maven Central for oracle.spectra.bundles:*. This adds a resolvability gate to issue triage that catches it in one HTTP request.

The gate deliberately does only the deterministic check. Two richer designs were considered and dropped:

• Adding more repositories to the build config. Tallying groupIds across all 53 human-intervention requests shows the "public library on a repository we don't configure" case is close to empty: 18 org.springframework.boot, 8 io.opentelemetry.instrumentation, 6 org.springframework.ai and the rest are on Maven Central already and stuck for unrelated reasons. The only non-Central coordinates are the Oracle-internal ones this issue is about. Extra repositories would also be consulted for every resolution in the whole suite, which costs latency and widens the dependency-confusion surface.
• An agent lookup for "where is this published?" GitHub Models turns out to be retiring, both models.github.ai/catalog/models and the inference endpoint return 410 github_models_retirement_brownout, and every remaining option needs a model API secret in the triage path. Not worth it for a case the data says barely occurs.

How the check decides

Resolution is a closed-world search: Gradle only ever asks the repositories declared in org.graalvm.internal.tck.gradle, so a miss proves absence from those repositories, never that the artifact does not exist. The gate is built around that limit. It probes the POM, and on a miss maven-metadata.xml, across Maven Central and Confluent, and acts only on a result it can prove:

Probe result	What it proves	Action
POM 200 anywhere	artifact resolves	triage continues, no comment
anything other than a definite 404	nothing	triage continues, no comment
POMs all 404, metadata 200	version absent, artifact exists	close as version-missing
everything 404	artifact absent	close as unresolvable

A 404 is the server stating it looked and the file is not there. A 5xx, a 401, or a timeout is not an answer at all, so it can never close an issue. This matters because triage runs unattended on issues: [opened]: without that rule a Maven Central outage would auto-close and comment on every request opened during it.

Verified against real coordinates:

oracle.spectra.bundles:helidon-mp:2607.0.8  => unresolvable    (the reported case)
org.postgresql:postgresql:42.7.3            => no comment      (resolves on Central)
org.postgresql:postgresql:99.99.99          => version-missing
io.confluent:kafka-avro-serializer:8.2.1    => no comment      (resolves on Confluent)
a repository did not answer                 => no comment

The Confluent case is why the probe covers both repositories: a Central-only check would have closed a library the repository already supports.

Comment examples

Only the two closing outcomes comment. Because absence is unprovable, both messages ask rather than simply reject.

version-missing, for org.postgresql:postgresql:99.99.99:

Automated triage: org.postgresql:postgresql was found, but version 99.99.99 is not published to any repository this project builds against (Maven Central, Confluent).

This usually means the version in the issue title has a typo, or it has not been released yet.

Please open a new request with a published version of org.postgresql:postgresql in the title.

If these coordinates are valid and this triage is wrong, please reply here and we will take another look.

unresolvable, for oracle.spectra.bundles:helidon-mp:2607.0.8:

Automated triage: oracle.spectra.bundles:helidon-mp:2607.0.8 could not be resolved from any repository this project builds against (Maven Central, Confluent).

Metadata in this repository is always shipped together with a test that resolves the library and runs in CI on every change. When we cannot download the artifact, we cannot build that test, and we cannot re-verify the metadata as new versions are released, so we are unable to support the coordinates as requested.

If this artifact is published to a public repository we do not yet configure, please reply with the repository URL and we will consider adding it.

If this artifact is private or internal, we cannot access it, but you can generate the metadata yourself: run your application with the tracing agent and place the generated configuration in your application's META-INF/native-image directory. See https://www.graalvm.org/latest/reference-manual/native-image/metadata/AutomaticMetadataCollection/

If your native image fails inside a public library that this private artifact depends on, please open a request for that library's coordinates and include the error, which we can act on.

Behavior is specified in §CI-triage-new-issues; the dependency-graph expansion gate now also excludes both closing outcomes, so a closed issue never fans out into transitive dependency issues.

Open questions

1. The three motivating issues stay open. The workflow triggers on issues: [opened], so it will not retroactively touch Support for oracle.spectra.bundles:helidon-mp:2607.0.8 #7767-Support for oracle.spectra.bundles:ucpwrapper-helidon-se:2607.0.8 #7769. I'd close them by hand with the same explanation.
2. Already-labeled issues can still reach the agents before triage ever sees them. A matching preflight in add_new_library_support.py would close that path; I left it out to keep this change to triage.
3. The repository list is duplicated between the workflow and org.graalvm.internal.tck.gradle, now stated as a requirement in the spec because mavenCentral() has no URL literal to extract. A Gradle task printing resolved repository URLs would remove the drift risk if that seems worth it.