fix: handle URIs with encoded spaces in applyEdit [IDE-1555] (#746)

* fix: handle URIs with encoded spaces in applyEdit [IDE-1555]

- Replace VirtualFileManager.findFileByUrl() with toVirtualFileOrNull()
  which properly decodes URL-encoded characters (e.g., %20 to spaces)
- Add debug logging to applyEdit and DocumentChanger to trace URI handling
- Fixes issue where applyEdit failed for paths containing spaces, dots, and underscores

The issue was that findFileByUrl() doesn't handle URL-encoded URIs.
Using toVirtualFileOrNull() converts the URI to a path first, which
automatically decodes %20 to spaces, then finds the file using the decoded path.

* refactor: use modern logger pattern in DocumentChanger

Replace Logger.getInstance() with logger<DocumentChanger>() to match
the pattern used throughout the codebase

Author: acke

src/main/kotlin/snyk/common/editor/DocumentChanger.kt

@@ -1,14 +1,28 @@
 package snyk.common.editor
 
-import com.intellij.openapi.vfs.VirtualFileManager
+import com.intellij.openapi.diagnostic.logger
 import io.snyk.plugin.getDocument
+import io.snyk.plugin.toVirtualFileOrNull
 import org.eclipse.lsp4j.TextEdit
 
 object DocumentChanger {
+    private val logger = logger<DocumentChanger>()
+
     fun applyChange(change: Map.Entry<String, List<TextEdit>>?) {
-        if (change == null) return //TODO add log
+        if (change == null) {
+            logger.warn("applyChange called with null change")
+            return
+        }
         val fileURI = change.key
-        val virtualFile = VirtualFileManager.getInstance().findFileByUrl(fileURI) ?: return
+        logger.debug("applyChange: Attempting to find file by URI: $fileURI (length: ${fileURI.length})")
+
+        // Use toVirtualFileOrNull() which properly handles URI decoding (e.g., %20 to spaces)
+        // This converts the URI to a path first, which automatically decodes URL-encoded characters
+        val virtualFile = fileURI.toVirtualFileOrNull()
+        if (virtualFile == null) {
+            return
+        }
+
         val document = virtualFile.getDocument() ?: return
         // Our LS is coded to give us the TextEdits in ascending order, but we must apply them in descending order.
         // Imagine we had an edit that added 10 lines to the start of the file followed by an edit that added a line to the 4th line of the file,