Normalize Windows drive letter case in workspace document URIs

[Sanjays2402]

Closes #697

Windows drive letters are case-insensitive, so a client may send file:///C:/foo (RFC 8089) or file:///c:/foo for the same file. uris.from_fs_path lower-cases the drive letter but Workspace._docs stored URIs verbatim, so the two spellings became separate dictionary keys — a document opened under one spelling was invisible under the other, and lookups silently fell back to stale on-disk content instead of the in-memory version.

Adds uris.normalize and uses it for every _docs key. Non-drive paths are unchanged. New tests fail without the fix and pass with it.

[ccordoba12]

Hey @Sanjays2402, thanks for your contribution! There's a test that started to fail on Windows due to your changes. Please try to fix it.

[Sanjays2402]

Fixed. The failure was drive-letter case in test_multiple_workspaces and test_multiple_workspaces_from_initialize: both peek directly into the private _docs dict with the raw client URI (file:///C:/...), but this PR keys that dict via uris.normalize(), which lower-cases the drive letter as uris.from_fs_path already did. So it was the test expectation that went stale, not the code over-normalizing — the public get_maybe_document() path was fine throughout. Wrapped the six _docs membership assertions in uris.normalize(); left the public-API and pylsp.workspaces folder-URI assertions alone since those keys aren't normalized. Pushed 6174437. Verified locally on macOS, where normalize() is a no-op, so Windows CI on this SHA is the real check.