Fix: 'Invalid 'col': out of range' When calling 'lua vim.lsp.buf.incoming_calls()'

[niexin-dev]

I use chatgpt5 fix this, please review

[niexin-dev]

修改总体思路
现在会在创建根节点和子节点时保存 LSP 响应使用的 offset_encoding，后续刷新高亮时才能知道列号的编码方式。这样即使不同语言服务器返回 UTF‑16、UTF‑8 或其它编码，Calltree 也能准确解释。

在写入或刷新 extmark 之前，统一调用新的 ensure_range_utf8，把 LSP range 中的列号转换成 Neovim 需要的 UTF‑8 字节列，同时根据实际缓冲区内容进行钳制，避免越界。

当 extmark 已存在时，会用 extmark 的最新位置回填节点或引用的 range，并打上 _litee_converted 标记，表示这些列号已经是安全的 UTF‑8 坐标，防止重复转换。

关键辅助函数
resolve_offset_encoding(ctx)：优先读取 ctx.offset_encoding，其次读取客户端配置，默认回退到 "utf-16"，保证每个节点都记录准确的编码信息。

clamp_line / clamp_col：在访问缓冲区之前先把行、列限制在当前缓冲区范围内，防止文件内容已被编辑或折叠变化时产生越界。

get_line_byte_from_position：必要时调用 vim.lsp.util._get_line_byte_from_position 把 UTF‑16 列号转成 UTF‑8 字节列；如果服务器已返回 UTF‑8，或者之前已经转换过，就直接复用原值，避免重复运算。

extmark 更新流程
首次创建：_update_calltree_extmarks 调用 ensure_range_utf8 获取安全的起止行列，然后用 nvim_buf_set_extmark 创建节点高亮和引用高亮；创建完成后把 extmark 信息缓存到节点里，方便后续刷新。

后续刷新：再次刷新时先读 extmark 的当前位置，再根据相对行列差更新节点/引用的 range，保持与缓冲区同步，避免“列号失效”导致的错误。

结果
即使文件包含中文、emoji、制表符等多字节字符，或在 Calltree 打开期间文件内容有所调整，_update_calltree_extmarks 也能得到正确的 UTF‑8 列号并钳制在合法范围内，从根本上消除 Invalid 'col': out of range 报错。