Fix invalid params error handling

[gabritto]

Found this while testing the fuzzer: if we failed to unmarshal params for a request, we weren't really sending the error message with the proper id (this was causing the fuzzer to hang). We were also using error code invalid request even when we should the more specific invalid params error.

[Copilot]

Pull request overview

This pull request fixes error handling for invalid JSON-RPC request parameters in the LSP server. Previously, when parameter unmarshaling failed, the server was using the generic InvalidRequest error code and wasn't properly preserving the request ID in the error response, which could cause issues like the fuzzer hanging.

Changes:

• Changed error code from InvalidRequest to the more specific InvalidParams when parameter unmarshaling fails
• Modified error handling to preserve and return the request ID in error responses for invalid params
• Added test coverage to verify the fix works correctly

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
internal/lsp/lsproto/jsonrpc.go	Moved error check after Message construction to allow ID extraction, changed error code to InvalidParams
internal/lsp/server.go	Added logic to detect InvalidParams errors and extract request ID from the partially unmarshaled message for error responses
internal/lsp/server_invalid_message_test.go	Added test to verify that invalid params trigger the correct error code and response includes the request ID

[gabritto]

Per the spec, if we fail to decode a request or notification (i.e. the whole thing, not just params), we are allowed to return an error response with null id.