fix(lsp): Windows-correct file:// URI conversion (jdtls no-op on Windows)

[avfirsov]

What

Centralises filesystem-path ↔ file:// URI conversion in a new leaf package internal/lspuri and routes all six previously hand-rolled sites through it, fixing a Windows-only bug that made the LSP layer (jdtls etc.) a silent no-op.

The bug

The naive "file://" + path is correct on POSIX — an absolute path already starts with /, so file:// + /repo/X.java = file:///repo/X.java (the required three slashes). On Windows it breaks:

• Outbound: C:\repo\Main.java → file://C:\repo\Main.java — the drive letter lands in the URI authority and backslashes aren't URI separators, so the server can't match the document we didOpen.
• Inbound: the server returns file:///C:/repo/Main.java; the old uriToPath took url.Parse(...).Path = /C:/repo/Main.java and did strings.HasPrefix(absPath, repoRoot) against C:\repo → always false → the result is silently dropped.

Net effect on native Windows: jdtls is detected and initialize succeeds, but every didOpen + definition/references/implementation round-trip no-ops — zero Java edges get enriched (ast_inferred → lsp_resolved), with no error logged. POSIX/macOS were unaffected, so it went unnoticed.

Fix

New internal/lspuri:

• PathToURI — C:\repo\Main.java → file:///C:/repo/Main.java; /repo/Main.java → file:///repo/Main.java (ToSlash, drive leading-slash, %xx-safe via net/url).
• URIToAbsPath — inverse, strips the spurious leading slash before a drive letter, FromSlash, decodes %xx.
• URIToRepoRel — uses filepath.Rel (case-insensitive on Windows) instead of a string prefix, so drive-casing / separators never cause a false miss.

Routed through it (all had the same bug class):

• internal/semantic/lsp/provider.go — pathToURI, uriToAbsPath, uriToPath
• internal/semantic/lsp/resolver_helper.go — uriToAbsLocalPath
• internal/mcp/diagnostics.go — pathToFileURI
• internal/mcp/tools_simulate.go — normaliseEditURI (now also decodes %xx and drops the host via url)

Tests

internal/lspuri unit tests exercise the drive-letter / separator logic via pure helpers, so the Windows behaviour is verified on the Linux/macOS CI runners (Windows only builds in CI, it doesn't run the suite). go build ./..., go vet, internal/lspuri and internal/mcp suites pass. (Pre-existing unrelated failure TestPassiveProvider_DialFailsNoFallback reproduces on main without this change — it needs a live LSP server.)

Follow-up (not in this PR)

If jdtls still under-resolves after this, the next suspects are async readiness (no wait for jdtls workspace-import to finish before querying) and Java-project recognition (no pom.xml/build.gradle ⇒ no classpath).