windows: drop the powershell dependency for user directories, and unify CI on one shell

[oyvindberg]

Windows CI kept a parallel universe of eight shell: cmd / shell: pwsh steps beside the unix ones. The reason was real: bleep could not resolve its own cache and config directories without spawning PowerShell, and nesting that inside a pwsh step is a known way to break it. This removes the cause, then the workaround.

The bug

Every bleep invocation on Windows ran:

powershell.exe -NoProfile -EncodedCommand <base64>

whose script is Add-Type @"...[DllImport("shell32.dll")] SHGetKnownFolderPath..."@ — it compiles C# at runtime to make one Win32 call. Main._main does this before anything else, and the BSP server does it from five more places, none memoized. That is the startup cost, and each spawn is a hard failure point: PowerShell in Constrained Language Mode (#43), AppLocker/WDAC, powershell.exe off PATH (#29), a non-writable TEMP, or a PSModulePath inherited from a parent pwsh that breaks Add-Type (PowerShell#8863).

Why it happened

The fix already shipped in code we depend on — it was just unreachable. coursier-cache 2.1.24 carries an FFM implementation under META-INF/versions/23, but that jar has no MANIFEST.MF at all, so no Multi-Release: true, so the JDK never loads it. And WindowsJni gates the JNI path off for java >= 23 precisely because it expects the multi-release class to take over. Both escape hatches closed; PowerShell every time.

coursier split coursier-paths out in 2.1.25 with a proper Multi-Release: true manifest. Verified rather than assumed:

JDK 21 -> coursier.paths.shaded.dirs.impl.WindowsPowerShell
JDK 25 -> coursier.paths.shaded.dirs.impl.WindowsForeign

coursier.cache.shaded.dirs no longer exists in 2.1.25, so UserPaths had to move regardless.

Native image

FFM downcalls need foreign reachability metadata or the image aborts with MissingForeignRegistrationError — the same failure class as #601, which stayed invisible until a real Windows user hit it. Registered SHGetKnownFolderPath's descriptor, and selftest now prints and validates the resolved directories so CI has to link them. The BSP server JVM gets --enable-native-access=ALL-UNNAMED on JDK 22+, which the native image already passed.

Cost of the bump

73 deprecation sites across 12 files, all load-bearing under -Werror. New internal/coursierDeps.scala converts at the two boundaries where coursier generalised a type bleep cannot express (Gradle Module variants) — throwing rather than defaulting; note coursier's own deprecated dependencyArtifacts silently collects those away. CoursierResolver.Result deliberately stays the narrower shape, keeping the on-disk resolution cache format byte-identical.

The 1094-file snapshot diff is pure reordering — coursier 2.1.25 emits resolution modules in a different order. Zero semantic change under an order-insensitive comparison, and a second run produces no further drift.

CI

Every step is now shell: bash on every OS; the only per-OS difference is the name of the two generated launcher scripts. bash also means set -eo pipefail, so every exit code is load-bearing — the old cmd blocks propagated only the last command's status, which is how 42 Windows test failures stayed hidden behind green runs (#607).

graalvm/setup-graalvm@v1 and the JAVA_HOME override in GenNativeImage are both gone. That override dated to GraalVM 21 and said "the one we install ourselves does not work"; neither reason survives on graalvm-community 25. Read out of the actual Windows distribution bleep provisions:

bin/native-image.cmd   present   <- what NativeImagePlugin resolves
bin/java.exe           present
bin/gu                 ABSENT    <- so the gu-install fallback is dead code

native-image.cmd locates lib/svm/bin/native-image.exe purely relative to itself and never reads JAVA_HOME, and since GraalVM for JDK 17/20 it finds Visual Studio via vswhere and sets up MSVC itself.

Drive-by fix: the Windows cleanup step looked for the BSP classpath cache under %USERPROFILE%\.bleep\cache — a directory bleep has never used on Windows (UserPaths.cacheDir is %LOCALAPPDATA%\bleep\cache, confirmed against a runner log). It matched nothing on every run, so the dev script could resolve bleep-bsp from a pre-publish classpath. It now warns and lists the directory rather than silently no-op'ing.

Verification

Full build green; 906 tests pass, 0 failed including slow ITs; selftest resolves unchanged macOS paths.

Not verified by execution, and the reason to review the CI commit separately: the Git Bash mechanics on a Windows runner (taskkill //F, cygpath, invoking ./ni-build.cmd from bash) and "GraalVM 25 finds VS 2022 on windows-latest". CI is the only way to check those.

Also loses native-image-job-reports — the action's PR size/metrics comment. Replacing it via $GITHUB_STEP_SUMMARY is planned separately.

🤖 Generated with Claude Code