fix(client): VimwikiColorize passes its {color} arg on Neovim + visual fix

The Neovim command defs for :VimwikiColorize / :NuwikiColorize were
-nargs=1 but called colorize() without <q-args>, so the colour name was
silently dropped and the user was prompted instead (the Vim branch passed
it correctly). Pass <q-args>.

While verifying, found a second bug in the Lua colorize(): it inferred
visual-vs-normal from vim.fn.visualmode(), which returns the *last* visual
mode used in the session along with stale '< / '> marks. So running
:VimwikiColorize in normal mode after any earlier visual selection wrapped
that leftover selection instead of the word under the cursor (produced an
empty, misplaced span). colorize(color, visual) now takes an explicit
visual flag, passed only by the x-mode <Leader>wc mapping; the command and
the normal-mode mapping always wrap the cword.

Tests: cmd.VimwikiColorize_uses_arg, cmd.NuwikiColorize_uses_arg,
cmd.Colorize_ignores_stale_visual_selection, colorize.visual_wraps_selection
in test-keymaps.lua. nvim suite 267, vim suite 254+18, all green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

development/tests/test-keymaps.lua

@@ -716,6 +716,52 @@ vim.defer_fn(function()
   -- a populated diary, but at least confirm the maps fire without
   -- error.
 
+  -- ===== Colorize commands pass their {color} arg (regression) =====
+  -- :VimwikiColorize / :NuwikiColorize are -nargs=1; the Neovim defs used to
+  -- call colorize() without <q-args>, silently dropping the colour and
+  -- prompting instead. Run the real commands and assert the colour lands.
+  tobj_case('cmd.VimwikiColorize_uses_arg', function()
+    set_buf({ 'word here' })
+    vim.api.nvim_win_set_cursor(0, { 1, 0 })
+    vim.cmd('VimwikiColorize red')
+    local got = vim.api.nvim_get_current_line()
+    if got ~= '<span style="color:red">word</span> here' then
+      error('VimwikiColorize dropped its arg: ' .. got)
+    end
+  end)
+  tobj_case('cmd.NuwikiColorize_uses_arg', function()
+    set_buf({ 'second word' })
+    vim.api.nvim_win_set_cursor(0, { 1, 0 })
+    vim.cmd('NuwikiColorize #00ff00')
+    local got = vim.api.nvim_get_current_line()
+    if got ~= '<span style="color:#00ff00">second</span> word' then
+      error('NuwikiColorize dropped its arg: ' .. got)
+    end
+  end)
+  -- Establish a stale visual selection, then confirm the normal-mode command
+  -- still wraps the cword (not the leftover selection) — the visualmode()
+  -- heuristic regression.
+  tobj_case('cmd.Colorize_ignores_stale_visual_selection', function()
+    set_buf({ 'alpha beta gamma' })
+    vim.cmd('normal! 0vee\27') -- select 'alpha beta', leave marks behind
+    vim.api.nvim_win_set_cursor(0, { 1, 11 }) -- on 'gamma'
+    vim.cmd('VimwikiColorize blue')
+    local got = vim.api.nvim_get_current_line()
+    if got ~= 'alpha beta <span style="color:blue">gamma</span>' then
+      error('command wrapped stale selection instead of cword: ' .. got)
+    end
+  end)
+  -- The visual mapping path (explicit visual=true) wraps the selection.
+  tobj_case('colorize.visual_wraps_selection', function()
+    set_buf({ 'one two three' })
+    vim.cmd('normal! 0wviw\27') -- visually select 'two', marks set on exit
+    require('nuwiki.commands').colorize('red', true)
+    local got = vim.api.nvim_get_current_line()
+    if got ~= 'one <span style="color:red">two</span> three' then
+      error('visual colorize did not wrap selection: ' .. got)
+    end
+  end)
+
   -- ===== Wiki picker (config-driven, no LSP) =====
   -- The picker must build its list from config so it works from any buffer
   -- before the server attaches.

development/vimwiki-gap.md

@@ -121,11 +121,19 @@ fix site.
 - [ ] `:VimwikiSearch` / `VWS` uses `lvimgrep`, not vimwiki's search engine.
 - [ ] `VimwikiIndex` family is buffer-local in nuwiki (upstream defines globally
   in `plugin/`); only `:…UISelect` is a global entry point.
-- [ ] **`VimwikiColorize` / `NuwikiColorize` drop their argument in the Neovim
-  branch** — both are `-nargs=1`, but the Neovim defs call `colorize()` with no
-  `<q-args>` (`ftplugin/vimwiki.vim:445,517`) while the Vim branch passes it
-  (`:106,177`). The color name is silently ignored under Neovim (real bug, not
-  just parity). _Fix:_ `ftplugin/vimwiki.vim` Neovim branch.
+- [x] **`VimwikiColorize` / `NuwikiColorize` drop their argument in the Neovim
+  branch** — both are `-nargs=1`, but the Neovim defs called `colorize()` with no
+  `<q-args>` (`ftplugin/vimwiki.vim:445,517`) while the Vim branch passes it. The
+  color name was silently ignored under Neovim (real bug, not just parity).
+  _Fix:_ Neovim command defs now pass `<q-args>`. While verifying, found a second
+  bug: `colorize()` inferred visual-vs-normal from `vim.fn.visualmode()`, which
+  returns the *last* session visual mode with stale `'<`/`'>` marks — so the
+  normal-mode command wrapped a leftover selection instead of the cword.
+  `colorize(color, visual)` now takes an explicit `visual` flag passed only by
+  the `x`-mode `<Leader>wc` mapping (`lua/nuwiki/keymaps.lua`); the command and
+  normal mapping always wrap the cword. Covered by `cmd.VimwikiColorize_uses_arg`,
+  `cmd.Colorize_ignores_stale_visual_selection`, and
+  `colorize.visual_wraps_selection` in `development/tests/test-keymaps.lua`.
 - [ ] **`VimwikiTableMoveColumn{Left,Right}` dispatch to different backing names
   per client** — Vim branch → `table_move_left/right`; Neovim branch →
   `table_move_column_left/right`. Harmless today (each name exists in its own