LSP: ignore redundant textDocument/didClose notifications

[sm18lr88]

Summary

ty server logs an ERROR when it receives textDocument/didClose for a document that is not registered as open in the current session. The server remains running, but this turns a stale client notification into noisy error output.

The LSP client should normally send didClose only for a document it opened. Even so, a server can receive a stale close during client/server restart or teardown. It would be more robust for ty to ignore that notification (or log it at debug/trace level) rather than report it as an error.

Minimal reproduction

Start ty server, complete the normal initialize / initialized handshake, and send this notification without first sending textDocument/didOpen for the URI:

{
  "jsonrpc": "2.0",
  "method": "textDocument/didClose",
  "params": {
    "textDocument": {
      "uri": "file:///D:/repro/unopened.py"
    }
  }
}

Actual result

The server writes an error such as:

ERROR An error occurred while running textDocument/didClose: document not found for key: D:\\repro\\unopened.py

Expected result

The server should safely ignore a redundant/stale close notification and continue without an error-level log entry. A regression test could cover an unmatched didClose after initialization.

Environment

• Windows
• Python 3.13
• Reproduced with ty 0.0.78 and 0.0.80

Duplicate check

I checked the existing LSP lifecycle reports before filing. #3995 concerns rename events that were not delivered to the server, #3061 concerns concurrent didOpen requests, and #2346 concerns stale semantic tokens after a valid close/reopen sequence. None covers handling an unmatched didClose itself.