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/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