feat(commands): VimwikiSplitLink/VSplitLink -nargs=* signature parity (P3)

Upstream's :Vimwiki[V]SplitLink take optional reuse_other_split_window +
move_cursor flags (the link is always the one under the cursor); nuwiki's defs
took no args, so `:VimwikiSplitLink 0 1` raised E488. All eight defs (both
clients × Split/VSplit × Vimwiki/Nuwiki) are now -nargs=*, restoring signature
parity for migrated configs/scripts.

Documented divergence: the two flags are accepted but not acted on — nuwiki
always opens a fresh split and follows in it. Honoring move_cursor/reuse would
require threading a completion callback through the async LSP follow path,
disproportionate for this rarely-used arg form; the no-arg path (99% case) is
fully equivalent. The gap-doc note (which wrongly described the args as a
"target link") is corrected.

Test: cmd.VimwikiSplitLink_accepts_args (test-keymaps-vim.vim, no E488).

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

development/tests/test-keymaps-vim.vim

@@ -669,6 +669,26 @@ call s:record(
       \ 'cmd.VimwikiListChangeLvl_accepts_range_and_args',
       \ 'err=' . s:lcl_err)
 
+" ===== :VimwikiSplitLink -nargs=* =====
+" Upstream takes optional reuse/move-cursor flags; nuwiki's defs took none, so
+" `:VimwikiSplitLink 0 1` raised E488. Now -nargs=*: assert the arg parse
+" succeeds. The split opens a window (the follow itself is an LSP no-op here);
+" collapse back to one window afterward.
+call s:set_buf(['[[Target]]'])
+let s:sl_err = ''
+try
+  silent VimwikiSplitLink 0 1
+catch /E488/
+  let s:sl_err = v:exception
+catch
+  " non-E488 (e.g. no LSP attached) is expected and fine here.
+endtry
+silent! only
+call s:record(
+      \ s:sl_err ==# '' ? 1 : 0,
+      \ 'cmd.VimwikiSplitLink_accepts_args',
+      \ 'err=' . s:sl_err)
+
 " ===== Wrap up =====
 
 call add(s:results, '')

development/vimwiki-gap.md

@@ -267,12 +267,20 @@ fix site.
   (bare `:VimwikiColorize` prompts). Covered by
   `normalize.visual_wraps_selection` (vim) /
   `cmd.normalize_link_visual_wraps_selection` (nvim).
-- [ ] **`VimwikiSplitLink` / `VimwikiVSplitLink` lack `-nargs=*`** _(new,
-  2026-05-31 third re-audit)_ — upstream both take an optional target link to
-  follow in the split; nuwiki's defs (both branches) take no args, so you can't
-  pass a link to the split-follow. Low impact (the arg path is rarely used).
-  _Fix:_ `ftplugin/vimwiki.vim` both branches + thread a target through
-  `follow_link_or_create`.
+- [x] **`VimwikiSplitLink` / `VimwikiVSplitLink` lack `-nargs=*`** _(new,
+  2026-05-31 third re-audit; corrected during the 2026-05-31 command-attribute
+  pass)_ — the earlier note was wrong: upstream's optional args are NOT a target
+  link but `reuse_other_split_window` (a:1) and `move_cursor` (a:2) — the link
+  is always the one under the cursor (`vimwiki#base#follow_link`). nuwiki's defs
+  took no args, so `:VimwikiSplitLink 0 1` (upstream muscle memory / migrated
+  scripts) raised E488. _Fix:_ all eight defs (both clients × Split/VSplit ×
+  Vimwiki/Nuwiki) are now `-nargs=*`, restoring signature parity. **Divergence
+  (documented):** the two flags are *accepted but not acted on* — nuwiki always
+  opens a fresh split and follows in it, because the follow is an async LSP
+  jump and honoring `move_cursor`/`reuse` would require threading a completion
+  callback through that path (disproportionate for this rarely-used arg form;
+  the no-arg case — the 99% path — is fully equivalent). Covered by
+  `cmd.VimwikiSplitLink_accepts_args` (`test-keymaps-vim.vim`, no E488).
 
 ### Config
 - [ ] `auto_header` — auto H1-from-filename on new page (server-side).