fix(commands): VimwikiTable default 5 cols (parity) + map audit findings

Verification audit of the command-attribute pass confirmed all four changes
(Table, Index/TabIndex, ListChangeLvl, SplitLink) faithful with no regressions,
and surfaced three pre-existing items:

- VimwikiTable no-arg default cols was 3 vs upstream's 5 (rows 2 already
  matched, confirmed against vimwiki#tbl#create). Aligned both backing fns
  (autoload + lua) to default 5 cols.

- Mapped (not fixed here — core <CR> behavior, out of attribute scope):
  the Neovim lua follow_link_or_create double-calls definition() with dead
  code and never wraps a bare word into [[link]] (the Vim side does); and the
  Neovim Split/VSplitLink dispatch to raw definition() instead of
  follow_link_or_create. Both logged in development/vimwiki-gap.md.

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

development/vimwiki-gap.md

@@ -183,6 +183,9 @@ fix site.
   cols/rows). Covered by `cmd.VimwikiTable_passes_cols_and_rows`
   (`test-keymaps.lua`, asserts a `:VimwikiTable 4 3` → 4-col, 3-row table) and
   `cmd.VimwikiTable_accepts_cols_rows` (`test-keymaps-vim.vim`, no E488).
+  Follow-up (same pass): the no-arg **default cols** diverged (nuwiki `3` vs
+  upstream `5`; rows `2` already matched — confirmed against upstream
+  `vimwiki#tbl#create`). Aligned both backing fns to default 5 cols.
 - [x] `VimwikiListChangeLvl` was `-nargs=?` (range-less) vs upstream
   `-range -nargs=+`. _Fix:_ all four defs are now `-range -nargs=+` passing
   `<line1>, <line2>, <f-args>`; `list_change_lvl(line1, line2, direction,
@@ -192,6 +195,19 @@ fix site.
   `cmd.ListChangeLvl_range_indents` (`test-keymaps.lua`) and
   `cmd.VimwikiListChangeLvl_accepts_range_and_args` (`test-keymaps-vim.vim`,
   no E481/E488).
+- [ ] **Neovim `follow_link_or_create` is botched** _(new, 2026-05-31
+  command-attribute audit)_ — `lua/nuwiki/commands.lua` calls
+  `vim.lsp.buf.definition()` **twice** with dead code between
+  (`local p = pos_args()[1]` … `local _ = p`), and never does the bare-word →
+  `[[link]]` wrap its docstring promises (the Vim side does, via
+  `s:wrap_word_under_cursor`). So on Neovim, `<CR>` on a bare word doesn't
+  create/follow a link, and link-follow fires a redundant second jump. _Fix:_
+  rewrite to wrap-then-jump once, mirroring the Vim path.
+- [ ] **Neovim SplitLink/VSplitLink skip the bare-word wrap** _(new, same
+  audit)_ — the Neovim defs dispatch to raw `vim.lsp.buf.definition()` while
+  the Vim defs (and Neovim `FollowLink`/`TabnewLink`) use
+  `follow_link_or_create`. Once the above is fixed, route Neovim
+  Split/VSplitLink through `follow_link_or_create` too for cross-client parity.
 - [x] `VimwikiRebuildTags` `-bang` ("rebuild all") — `:…RebuildTags!` now passes
   `{ all: true }`; the server (`tags_rebuild`) re-indexes **every** configured
   wiki (via `wikis_snapshot()`) instead of just the current one. `-bang` added to