22.5 Editor support

Hanki ships first-party Helix integration: an in-tree tree-sitter grammar (editor/tree-sitter-hanki/), Helix queries (editor/tree-sitter-hanki/queries/helix/), and the hanki lsp / hanki fmt toolchain commands. See docs/editor/helix.md for the languages.toml snippet and a zero-to-working-setup walkthrough.

The grammar tracks the language, and a CI task enforces that. It comes with use / open, provide, opaque, where, move, async / await and the leading-dot continuation line (§2), and the grammar task parses every tracked .hk file with a bar of zero failures; a floor would not notice a new file the grammar chokes on, since the count of passing ones does not drop. The same task compares grammar.js against the committed src/grammar.json (the generated parser a box without node builds from) and runs the corpus tests, which also validate every queries/*.scm against the node names the grammar produces.

The parse half also runs in the ordinary local suite (cargo nextest run), because its failure mode is produced by ordinary work: a new .hk file using a construct the compiler accepts and the grammar does not. Waiting for a submitted build to hear about it once left main red on this gate for a day. It costs about a second and a half, and skips when tree-sitter is not installed. The other two halves stay CI-only: both are about the generated artifact and not the language, and want the pinned CLI.

So an edit to grammar.js must be regenerated and committed together - tree-sitter generate --js-runtime native, which uses the CLI's built-in QuickJS so no node is needed.