fix: resolve draft note line ranges without line codes

[hektor]

Opening a review that has an unsubmitted draft note with a multi-line range crashes when the commented file's buffer enters a diffview window:

gitlab.nvim: Error setting diagnostics:
  lua/gitlab/actions/common.lua:268: attempt to perform arithmetic on local 'new_end_line' (a nil value)

The error is raised inside the DiffviewDiffBufWinEnter autocmd, so it propagates out of diffview's nvim_win_call and tears down the whole async chain — selecting that entry in the file panel fails with a wall of tracebacks, and the file never opens.

Cause

get_line_numbers_for_range derives the range purely from the two line codes. The draft_notes API leaves line_code empty inside line_range, and only fills in the line numbers:

"line_range": {
  "start": { "new_line": 495, "type": "new" },
  "end":   { "new_line": 500, "type": "new" }
}

parse_line_code("") returns nil, nil, so new_end_line - new_start_line is arithmetic on nil. (PositionInfo.line_code is already annotated as optional in annotations.lua.)

Fix

get_line_numbers_for_range now takes the two PositionInfo tables instead of two line-code strings, and resolves each end with parse_range_end: parse the line code, fall back to the old_line / new_line the range end already carries. Both call sites (get_line_number_from_node, create_multiline_diagnostic) pass the tables.

Testing

tests/spec/common_line_range_spec.lua covers a NEW SHA range, an OLD SHA range, and the draft-note range with empty line codes. Suite goes 69 → 72, all passing. stylua --check . and luacheck are clean.

Verified against a real MR with two draft notes (lines 28 and 495–500): before the change, opening that file crashed; after, the diagnostics land at lnum=27 end_lnum=27 and lnum=494 end_lnum=499.

[jakubbortlik]

Hi @hektor, did you close it because it's duplicate of #587 and #593? A word of explanation would actually be helpful. And since this is the third such PR in a row, it would be helpful if people helped to figure out why this has started happening - where do these "incomplete" line ranges come from? My guess is that they are created by AI agents.