file_watcher: duplicate path_to_uri still uses bare format!("file://{}")

[bug-ops]

Description

file_watcher.rs contains a second path_to_uri implementation (around line 336) that still uses the old format!("file://{s}") pattern without percent-encoding reserved characters. PR #151 fixed the copy in bridge/state.rs but left this one untouched.

As a result, file-change notifications silently fail to trigger on paths containing [, ], ^, or | — the exact class of filenames PR #151 was designed to support (Next.js dynamic routes, etc.).

Reproduction Steps

1. Open a project with a file named [slug].ts in the workspace root.
2. Edit and save the file.
3. Observe: LSP diagnostics / file-watching events are not forwarded because the URI sent in textDocument/didChange is unencoded while the URI registered in textDocument/didOpen (via bridge/state.rs) is encoded — they no longer match.

Expected Behavior

Both URIs should be identical; reserved characters percent-encoded consistently.

Actual Behavior

file_watcher.rs produces file:///path/[slug].ts; state.rs produces file:///path/%5Bslug%5D.ts — LSP server sees them as different documents.

Fix

Route file_watcher.rs:path_to_uri through the same encode_rfc3986_path_chars helper introduced in PR #151, or call Url::from_file_path directly (as the fixed implementation does).

[ebbsanchez]

I checked this against current main (281381bd8b292e59e3e837729fd909c7337c316c) and I think this issue may be stale after the file-watching refactor.

Verification:

rg -n "file_watcher|path_to_uri|format!\(\"file://" crates/mcpls-core/src -S
cargo test -p mcpls-core path_to_uri -- --nocapture

Findings:

• I could not find file_watcher.rs or a second path_to_uri implementation in crates/mcpls-core/src on current main.
• The only exported helper appears to be crates/mcpls-core/src/bridge/state.rs::path_to_uri.
• The filtered path_to_uri tests pass locally: 2 passed, 0 failed.

There are still other raw file:// construction sites (lsp/lifecycle.rs, bridge/resources.rs), but I do not see the specific duplicate implementation described here anymore. If those remaining sites are still problematic, this issue may need to be re-scoped to one of them; otherwise it may be ready to close as stale/resolved by refactor.