Parser-error diagnostic emits zero-length `Range`; clients drop the squiggle

What happens

In src/server.ts, parser-error diagnostics are emitted with start and end at the same position:

range: {
    start: { line: error.line - 1, character: error.column },
    end:   { line: error.line - 1, character: error.column }
},

The resulting range has zero length. LSP 3.17 does not forbid empty ranges, so this is not a spec violation, but it is consistently bad UX:

• VSCode renders a zero-length range as a single-character caret under the next character, hiding which token actually triggered the error.
• Several other clients (older vim-lsp, some eglot versions) drop zero-length diagnostics entirely from the highlighted-errors list, so the user sees no squiggle at all and has to consult the "Problems" panel to discover there is an error.

A parser error generally points at a specific token; the token's start column is already in hand, and its length is recoverable from the parser state.

What should happen

Either extend the range by one character so every client paints at least a single squiggle:

end: { line: error.line - 1, character: error.column + 1 }

…or, better, set the end to the end of the offending token (if the parser exposes the token length). Result: every LSP client surfaces parser errors as a visible squiggle, instead of silently dropping or rendering them as an invisible caret.