fix(client): honor count on Neovim Index; log third re-audit findings

Third audit pass (config/mappings/commands vs vimwiki master) confirmed all
recent range/bang/visual and diary-week work is present and correct in both
clients, with no regressions, and that Neovim does bind the text objects.

It surfaced one real oversight: the Neovim Vimwiki/NuwikiIndex commands still
read vim.v.count (always 0 in command context) instead of <count> — the same
bug the TabIndex fix addressed, but Index was missed. Fixed both to <count>,
so :2NuwikiIndex now opens wiki 2.

Gap doc updated: new open item (VimwikiSplitLink/VSplitLink missing upstream
-nargs=*), mouse-maps-opt-in recorded as an intentional divergence, and the
third-pass summary. Suites green — nvim 274, vim 266+18.

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

development/vimwiki-gap.md

@@ -175,9 +175,10 @@ fix site.
   `nuwiki#commands#table_move_column_left/right` (existing aliases over the
   `table_move_left/right` impls), matching the Neovim branch.
 - [x] **`NuwikiTabIndex` lacks `-count` in the Neovim branch** — added `-count`;
-  also switched both Neovim `Vimwiki/NuwikiTabIndex` from `vim.v.count` (always 0
-  in command context) to `<count>`, so a `:NNuwikiTabIndex` count is now actually
-  honored.
+  also switched the Neovim `Index`/`TabIndex` family (`Vimwiki/NuwikiTabIndex`
+  and `Vimwiki/NuwikiIndex`) from `vim.v.count` (always 0 in command context) to
+  `<count>`, so a `:2NuwikiIndex` / `:3NuwikiTabIndex` count is now honored.
+  (The `Index` half was caught by the 2026-05-31 second re-audit and fixed then.)
 - [x] **`VimwikiToggleListItem` / `Increment` / `DecrementListItem` `-range`** —
   all three (both branches) are now `-range`; the client loops the per-line op
   over `[<line1>, <line2>]` (`toggle_list_item_range` / `list_cycle_symbol_range`).
@@ -203,6 +204,12 @@ 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`.
 
 ### Config
 - [ ] `auto_header` — auto H1-from-filename on new page (server-side).
@@ -255,6 +262,9 @@ audits don't re-flag them.
 - `key_mappings` (dict) — replaced by Lua `mappings.<group>` + the
   `g:nuwiki_no_<group>_mappings` globals.
 - `use_calendar` — no calendar.vim integration.
+- Mouse maps (`<2-LeftMouse>`, `<MiddleMouse>`, …) — upstream binds them
+  unconditionally; nuwiki ships them **opt-in** (`mappings.mouse` /
+  `g:nuwiki_mouse_mappings`). Deliberate, so they're not always-on.
 - `global_ext` (upstream `1`) — nuwiki's ftdetect always maps the configured
   wiki extension(s) to the `vimwiki` filetype regardless of location; there's no
   per-wiki "only inside the root" toggle. Effectively always-on, like
@@ -281,3 +291,11 @@ audits don't re-flag them.
   clients. New gaps from that pass (diary-note `-count`, `-complete` specs,
   `<D-CR>`, global `<Leader>w<Leader>m`, plus `global_ext`/`syntax`-name notes)
   were added above; no previously-closed item regressed.
+- Re-audited again 2026-05-31 (third pass) after the range/bang/visual and
+  diary-week work. All those fixes confirmed in both clients; no regressions.
+  Confirmed Neovim **does** bind the text objects (`nuwiki.textobjects.attach`).
+  Found + fixed an oversight (Neovim `Vimwiki/NuwikiIndex` still read
+  `vim.v.count`; now `<count>`, completing the `TabIndex` fix). New gaps logged:
+  `VimwikiSplitLink`/`VSplitLink` missing `-nargs=*`; mouse-maps-opt-in noted as
+  an intentional divergence. Config pass found no new gaps; all shipped defaults
+  match upstream except the documented `syntax`-name divergence.