`export --json`: Provide tooling versions (e.g. Native CLI)

[kubukoz]

scala-cli export --json is currently useful for downstream tooling, but it does not expose enough information to faithfully reproduce scala-cli package, especially for Native.

For tools like scala-cli-nix, the gap is that export --json mostly exposes project-level metadata and declared dependencies, while scala-cli package operates on a richer, fully resolved graph that includes
platform rewriting, implicit runtime/tooling artifacts, and packaging-time resolution choices.

As a result, a downstream tool can successfully inspect a project via export --json, yet still fail to reproduce scala-cli package --offline because the exported JSON does not contain the actual effective
artifact closure used by packaging.

What I'd like

scala-cli export --json should expose the full effective artifact resolution used by packaging for the selected platform/scope.

More specifically, it would be useful if export included machine-readable information for:

1. The full resolved artifact graph
   This should include all concrete artifacts after platform rewriting and transitive resolution. This is mostly (full?) working today.
2. Implicit tooling artifacts
   Packaging depends on artifacts that are not user-declared dependencies, for example:
   • Scala Native linker / CLI artifacts
   • Scala Native compiler plugin
   • other packaging-time helper artifacts Scala CLI adds internally
3. Effective runtime artifacts used by packaging
   Especially for Scala Native, this should include the actual resolved runtime modules used at package time, such as:
   • javalib
   • nativelib
   • posixlib
   • other implicit native runtime pieces
4. Role separation
   Ideally artifacts would be grouped by purpose, e.g.:
   • compiler artifacts
   • compile classpath
   • runtime classpath
   • tooling artifacts
   • packaging artifacts
5. Effective packaging/platform config
   Exporting the effective settings used by packaging would also help:
   • selected platform
   • selected Scala Native version
   • main class
   • effective native options such as mode / gc / lto / target / linker options

Why this matters

The goal is not just “describe the project”, but “describe the effective inputs to Scala CLI packaging”.

Without that, downstream tools cannot reliably:

• prefetch/package artifacts
• build offline
• mirror Scala CLI’s packaging behavior in deterministic environments like Nix

Today a downstream tool can only approximate this by combining:

• export --json
• hardcoded knowledge of Scala CLI internals
• extra independent resolution steps

That approximation breaks for Native dependency cases.

Suggested shape

Any of the following would solve the problem:

• extend export --json with resolved packaging artifacts
• add a new export mode specifically for effective resolution/package inputs
• add a dedicated machine-readable command for “what scala-cli package will resolve and use”

The important part is that the output should reflect the actual resolution/package-time closure Scala CLI uses, not just declared dependencies. Ideally, it would do this without actually building the package.

Minimal success criterion

A downstream tool should be able to:

1. run a machine-readable Scala CLI command once
2. get the complete artifact closure needed for scala-cli package --offline
3. prefetch those artifacts
4. run packaging offline successfully without reimplementing Scala CLI internals

Example downstream use case

scala-cli-nix wants to:

• inspect a Scala CLI project
• prefetch every artifact needed by packaging
• run scala-cli package --offline inside Nix