Don't crash on document URIs with an invalid scheme

[eyupcanakman]

Motivation

Closes #4067. A client can send a textDocument message whose URI uses a scheme Ruby's URI() parser rejects, which crashes the server and drops the connection. The Claude Code extension does this with its _claude_fs_right: and _claude_fs_left: inline-diff schemes, where the leading underscore is invalid under RFC 3986. BaseServer#start wraps the URI(uri) call only in rescue Store::NonExistingDocumentError, so URI::InvalidURIError escapes the reader loop.

Implementation

Rescue URI::Error next to the existing Store::NonExistingDocumentError rescue. The message then continues to normal dispatch, where process_message already returns an error response for requests and logs notifications, so a URI Ruby cannot parse no longer crashes the reader loop.

Automated Tests

Added a test that drives start with an invalid-scheme document URI and asserts the server stays up and still answers the request with an error.

[rafaelfranca]

Thank you for the patch, but the question in the issue remain. When and why is sending those URIs? We know it is claude code, but when does it send that, and why?

[eyupcanakman]

The schemes come from Claude Code's inline diff feature. When it proposes an edit it opens a native diff whose two sides are virtual documents under _claude_fs_left:/_claude_fs_right:, and the server gets a textDocument/didOpen carrying one of those URIs. Our documentSelector is only file and untitled, so VS Code's own sync would never send these, which means Claude's LSP integration is talking to the server directly. The underscore is invalid per RFC 3986 so URI() raises in the reader loop where we only rescued Store::NonExistingDocumentError, and the same URLs crash other servers too (rust-analyzer in anthropics/claude-code#1522).