Problem

sbt bspConfig writes the absolute path of the current Java binary into .bsp/sbt.json. When the user switches Java versions (via sdkman, cs java, etc.) or removes that JDK, the IDE fails to start the sbt BSP server because the hardcoded path is stale or gone.

Solution

When an sbt launcher script is available (via sbt.script system property or PATH lookup), generate:

"argv": ["/path/to/sbt", "bsp"]

instead of the old direct java invocation. The sbt script resolves Java from PATH/JAVA_HOME at runtime, so switching Java versions no longer breaks BSP.

Falls back to the previous direct java invocation when no sbt script is found (e.g. when sbt is launched from an IDE without the script on PATH).

Changes

• BuildServerConnection.scala - prefer sbt script as argv[0], fall back to direct java
• Main.scala, NetworkClient.scala - recognize "bsp" (without dash) as a BSP command
• sbt (bash) - handle bsp command: bypass native client, pass -bsp to Boot
• sbt.bat - handle bsp command: bypass native client
• sbtw/Main.scala - handle bsp in residual args: bypass native client

Test plan

• Unit tests added in BuildServerConnectionSpec (fallback argv structure, sbtScriptInPath)
• Integration test updated in BspConfigTest (accepts both sbt-script and java-direct formats)
• protocolProj/test - 10/10 passed
• commandProj/test - 42/42 passed
• scalafmtCheck - all passed
• Manual test: publishLocalBin, created test project, ran bspConfig, confirmed .bsp/sbt.json uses sbt script path
• Manual test: sbt bsp starts and exits cleanly (exit code 0)
• Manual test: fallback path (no sbt script) still produces direct java argv

Closes: #7245

Generated-by: Claude Opus 4.6