Add code actions to disable a check for a line or the whole file

[ryandiginomad]

What are you adding in this PR?

ESLint-style quick-fixes for theme-check diagnostics, as requested in #432. When a theme-check offense is under the cursor, two code actions are offered:

• Disable <Check> for this line — inserts {% # theme-check-disable-next-line <Check> %} on the line above, indentation-matched
• Disable <Check> for entire file — inserts {% # theme-check-disable <Check> %} at the top of the file

Actions are grouped by check name, so selecting a range containing several offenses of the same check yields a single pair (not one per offense).

The disable-comment consumer already lives in theme-check-common/disabled-checks; this PR only adds the producer — the code action that writes the comment for you — matching the scope @charlespwd clarified when reopening #432 ("the right click code transformation vs supporting it in code").

Implemented as a new DisableCheckProvider in theme-language-server-common, mirroring SuggestionProvider. Unlike FixProvider/SuggestionProvider (which dispatch a server command to run an offense's fix function), this provider carries the WorkspaceEdit directly, since the inserted text is known and needs no server-side computation. A small toEditCodeAction helper was added next to toCodeAction for that.

fixes #432

{% liquid %} blocks

Inside a {% liquid %} tag, comments are bare # lines rather than {% # %}, so a {% # %} insertion would be invalid there. For now the for this line action is suppressed when the offense is inside a {% liquid %} block (detected via findCurrentNode); for entire file is still offered (it inserts at the top of the file, always valid).

What's next? Any followup issues?

• Emit the bare-# theme-check-disable-next-line form for offenses inside {% liquid %} blocks (currently the line-level action is skipped there).
• When a single check has offenses both inside and outside a {% liquid %} block within one selection, the first-seen offense decides whether the line-level action is offered and where the comment lands. Happy to refine to per-offense handling if you prefer.

What did you learn?

theme-check-disable (no -next-line) disables from the comment to EOF, so the file-level action just inserts at the top — no need to track an end marker.

Tophatting

Verified with unit tests (mirroring SuggestionProvider.spec.ts) rather than manual VSCode tophatting — I don't have the extension running locally. Tests assert the exact WorkspaceEdit for both variants, grouping/dedup, multiple distinct checks, the no-offense case, and the {% liquid %} skip + outside-{% liquid %} cases. pnpm test for the package: 440 passed, type-check and prettier clean.

Before / after — choosing "Disable UnusedAssign for this line" on:

{% assign x = 1 %}

becomes:

{% # theme-check-disable-next-line UnusedAssign %}
{% assign x = 1 %}

• I added screenshots of the changes (before and after the changes if applicable) — N/A; before/after shown above, behavior covered by unit tests.

Before you deploy

• I included a minor bump changeset
• My feature is backward compatible

---

🤖 AI assistance disclosure — this PR was written with AI assistance (Claude Code). I directed the design (edit-based approach, the {% liquid %} v1 skip), reviewed every change, and it follows TDD with unit tests verified locally. I understand the code and can explain why it's correct.

Open to feedback on: (1) edit-based vs command-based (chose edit-based as there's nothing to compute server-side); (2) the {% liquid %} v1 skip vs emitting bare #; (3) the representative-offense behavior noted above.