fix(spring-boot): register classpath listener command globally

The "vscode-spring-boot.ls.start" command which starts the classpath
handshake between the editor and the Spring Boot LS is sent by the jdtls
extension, not by the Spring Boot LS itself. Where a client sends
"workspace/executeClientCommand", the handler resolves commands against
that same client's "commands" and the global table, so a per-client
registration on the "spring-boot" client is never consulted for it.

Move the command into the global vim.lsp.commands from a new
M.register_client_commands(), call it and M.init_lsp_commands() from
M.setup() so both exist before jdtls imports a Spring Boot project, and
drop the now-dead "commands" block from lsp/spring-boot.lua. Also expand
the comments explaining the split between per-client and global handlers.

Author: JavaHello

lsp/spring-boot.lua

@@ -82,8 +82,11 @@ return {
   end,
 
   handlers = {
-    -- The server asking the editor to run a command, e.g. to enable classpath
-    -- listening. Handled on this client, so no global handler is needed.
+    -- The server asking the editor to run a command by id. The commands
+    -- themselves live in |vim.lsp.commands|, registered by
+    -- |spring_boot.setup()|: the one the Spring Boot LS depends on is sent by
+    -- the *jdtls* extension, so it never reaches this client. See
+    -- |spring_boot.register_client_commands()|.
     ["workspace/executeClientCommand"] = function(err, result, ctx, config)
       return require("spring_boot").execute_client_command(err, result, ctx, config)
     end,
@@ -105,10 +108,4 @@ return {
     ["sts/javaCodeComplete"] = handler("java_data", "sts/javaCodeComplete"),
     ["sts/project/gav"] = handler("java_data", "sts/project/gav"),
   },
-
-  commands = {
-    ["vscode-spring-boot.ls.start"] = function()
-      require("spring_boot.util").boot_execute_command("sts.vscode-spring-boot.enableClasspathListening", { true })
-    end,
-  },
 }

lua/spring_boot.lua

@@ -25,9 +25,10 @@ local M = {}
 --- a command, possibly on another server. The command is resolved through the
 --- client that sent the request, so per-client `commands` win.
 ---
---- `lsp/spring-boot.lua` registers this on the `spring-boot` client, which is
---- enough on its own. See |spring_boot.init_lsp_commands()| for the global
---- variant.
+--- `lsp/spring-boot.lua` registers this on the `spring-boot` client, which
+--- covers the Spring Boot LS itself. The commands jdtls sends to its own client
+--- need the global variant installed by |spring_boot.init_lsp_commands()|,
+--- unless nvim-jdtls already provided one.
 --- see https://github.com/mfussenegger/nvim-jdtls/blob/29255ea26dfb51ef0213f7572bff410f1afb002d/lua/jdtls.lua#L819
 ---@type lsp.Handler
 M.execute_client_command = function(_, params, ctx)
@@ -67,6 +68,28 @@ M.init_lsp_commands = function()
   vim.lsp.handlers["workspace/executeClientCommand"] = M.execute_client_command -- luacheck: ignore 122
 end
 
+--- Registers the commands a server asks the editor to run through
+--- `workspace/executeClientCommand`.
+---
+--- These belong in the global |vim.lsp.commands| and not in the `spring-boot`
+--- config's `commands`, because the one that matters here is sent by the *jdtls*
+--- extension, once jdtls has imported a Spring Boot project — so it is
+--- dispatched on the `jdtls` client, whose handler resolves commands against
+--- that client and the global table only. A `commands` entry on the
+--- `spring-boot` client is never consulted for it.
+---
+--- This is the start of the classpath handshake: the command makes the editor
+--- ask the language server to listen for classpath changes
+--- (`sts.vscode-spring-boot.enableClasspathListening`), and without it the
+--- server never learns the project's classpath — no beans, no endpoints, no
+--- `application.properties` / `.yml` properties.
+--- see https://github.com/spring-projects/sts4/blob/cfd10f0b53be0bfe107ca91ae0ad3df3038b1af2/headless-services/jdt-ls-extension/org.springframework.tooling.jdt.ls.extension/src/org/springframework/tooling/jdt/ls/extension/JdtLsExtensionPlugin.java
+M.register_client_commands = function()
+  vim.lsp.commands["vscode-spring-boot.ls.start"] = function()
+    require("spring_boot.util").boot_execute_command("sts.vscode-spring-boot.enableClasspathListening", { true })
+  end
+end
+
 M.get_ls_from_mason = function()
   local result = M.get_from_mason_registry("vscode-spring-boot-tools", "language-server.jar")
   if #result > 0 then
@@ -162,6 +185,12 @@ M.setup = function(opts)
     return config
   end
 
+  -- The classpath handshake starts on jdtls' side, so both the handler and the
+  -- command have to be registered globally, before jdtls imports a Spring Boot
+  -- project. See |spring_boot.register_client_commands()|.
+  M.register_client_commands()
+  M.init_lsp_commands()
+
   -- Options may have changed, so workspaces are re-judged by `project_filter`.
   require("spring_boot.launch").clear_project_filter_cache()