fix: #165 disable completion in comments

[liuxy0551]

改动内容

#165

• 光标位于 SQL 注释内时，不再触发代码补全
• 通过当前语言的 Monarch tokenizer 判断注释状态，并在调用 worker/C3 前结束补全流程
• 正确区分块注释内部和 */ 之后的位置
• 新增单行注释、MySQL # 注释、块注释及非注释边界场景单测

预览地址

https://liuxy0551.github.io/monaco-sql-languages/

[Cythia828]

看看是否存在这个问题

[Cythia828]

每次补全请求都 getValueInRange 取光标前全部文本（一次大字符串分配），再 editor.tokenize 对整段做 Monarch 分词（又一次大字符串 + 分词）。建议补一个大文件 benchmark 确认回归可接受，如果发现延迟明显，可能需要切换到别的方案

[liuxy0551]

这个点已经调整了。

当前实现不再读取从文档开头到光标的整段文本，也不再调用 editor.tokenize 对整段前缀重新分词；改成基于 Monaco model 的 tokenization.tokenizeLinesAt()，只对当前行光标前的内容追加哨兵字符后做按行 token 判断。

同时补了一个回归测试，确保注释检测不会再去读取整段文档前缀。

benchmark 这次我先不放在这个 PR 里，主要是 dt-sql-parser 才有 benchmark 流程。主要是这里的改动范围仍然是共享 CompletionAdapter 的实现收敛，当前也已经从“整段前缀复制 + 整段重分词”收敛到“按行 token 判断”。

[liuxy0551]

看看是否存在这个问题

这里确实是依赖各方言 Monaco tokenizer 的注释识别结果来决定是否关闭补全。

当前实现的目标是：一旦光标已经处于该方言 tokenizer 识别出的注释区域内，就在 Monaco 层直接短路，不再触发 worker、C3 和 completionService。

因此像 MySQL 这类方言，如果其现有 tokenizer 会把某些输入识别为注释，这次补全逻辑会沿用同一套方言语义，不会再单独引入另一套注释判定规则。本次 PR 只收敛在共享 CompletionAdapter，不调整各方言 tokenizer 或 dt-sql-parser 的注释定义。