fix(lsp): semantic tokens ignore 'fileformat' when sizing line endings #41733

Problem:
The eol_offset used to decode multiline semantic tokens is computed as

    vim.bo.fileformat[bufnr] == 'dos' and 2 or 1

which indexes the option value rather than the buffer, so it is never
"dos" and the offset is always 1. A token that crosses a line boundary
in a 'fileformat' of "dos" is then decoded one code unit short per line
ending, and the highlight extends past the end of the token.

Solution:
Read the option with the buffer-scoped form, vim.bo[bufnr].fileformat.

The existing multiline test covers both formats now. Its token length of
82 counts the line endings it spans, so the same token reaches four
characters less far once the buffer is "dos".

AI-assisted

runtime/lua/vim/lsp/semantic_tokens.lua

@@ -88,7 +88,7 @@ local function tokens_to_ranges(data, bufnr, client, request, ranges)
   local encoding = client.offset_encoding
   local lines = api.nvim_buf_get_lines(bufnr, 0, -1, false)
   -- For all encodings, \r\n takes up two code points, and \n (or \r) takes up one.
-  local eol_offset = vim.bo.fileformat[bufnr] == 'dos' and 2 or 1
+  local eol_offset = vim.bo[bufnr].fileformat == 'dos' and 2 or 1
   local version = request.version
   local request_id = request.request_id
   local last_insert_idx = 1