native-image compile fails due to a residual SUBST pointing to Coursier‑managed GraalVM ZIP

[philwalk]

Version(s)
Scala CLI version: 1.11.0
Scala version (default): 3.7.4

Describe the bug
On Windows, scala-cli package --native-image attempts to reuse existing SUBSTed letters, and also leaks SUBST drive mappings, causing failed --native-image compiles.

Summary:
On Windows, NativeImage uses subst to shorten long GraalVM home paths before invoking native-image. The method for choosing an available drive letter only avoids drive letters that correspond to actual physical storage, but must also check to see if a drive letter has already been mapped via the SUBST cmd.

To Reproduce
The following steps should reproduce this bug.
Assuming I: is the first available drive not corresponding to physical storage, map it to an existing path:

subst I: c:\tmp

The next attempt to compile should crash with a stackdump that reports Drive already SUBSTed.

scala-cli --power package --native-image hello.sc -- --no-fallback
Drive already SUBSTed
Error: os.SubprocessException: Result of cmd…: 1

For more details, ...

The cause is that NativeImage#availableDriveLetter() only checks physical drives and does not consider SUBST mappings.

Additionally, when a native image compile is interrupted, it sometimes leaves behind a SUBSTed drive letter.

Expected behaviour

• native-image compiles in Windows should:

1. Detect when a drive letter is already SUBSTed.
2. Validate that SUBST succeeded before invoking native-image.
3. clean up SUBST mappings via a shutdownhook rather than try/finally block

And possibly also reclaim stale mappings that point into Coursier/GraalVM cache directories.