fix(vars): resolve wiki by index in the vimwiki compat shim (R15)

`vimwiki#vars#get_wikilocal(key, N)` previously ignored the wiki-index
argument and always read the scalar `g:nuwiki_*` globals (the first
wiki), so third-party plugins (vimwiki-sync, vim-zettel) got the wrong
wiki's path/ext/syntax in a multi-wiki setup.

Now:
- an explicit numeric index selects that wiki from `g:nuwiki_wikis[N]`,
  falling back per-key to the scalar globals;
- with no index, the wiki owning the current buffer is resolved (matching
  upstream's `g:vimwiki_current_idx` behaviour);
- an out-of-range index clamps to the first wiki.

The single-wiki shorthand path is unchanged. Verified with a headless
Vim test (by-index, global fallback, clamp, no-arg, shorthand) and the
Vim keymap harness (301/18/21, 0 failed).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

development/vimwiki-gap.md

@@ -856,9 +856,13 @@ re-audit confirmed no regressions.
   single-keypress paths over small inputs — regression risk outweighs the gain.)_
 - [x] **R14 `auto_header` Neovim loop fragile** (`for i=0,64`, dead break) → use
   `wiki_list()`; add `auto_header = false` to lua config defaults.
-- [x] **R15 `autoload/vimwiki/vars.vim` shim ignores the wiki index** —
-  `get_wikilocal(key, N)` always returns wiki 0 (latent multi-wiki bug for
-  third-party plugins).
+- [x] **R15 `autoload/vimwiki/vars.vim` shim ignores the wiki index**
+  _(fully fixed 2026-06-03)_ — `get_wikilocal(key, N)` now resolves wiki `N`
+  from `g:nuwiki_wikis[N]` (falling back to the scalar `g:nuwiki_*` globals per
+  key); with no index it resolves the wiki owning the current buffer, matching
+  upstream's `g:vimwiki_current_idx` behaviour, and clamps an out-of-range index
+  to the first wiki. Multi-wiki third-party plugins (vimwiki-sync, vim-zettel)
+  now get the right wiki's `path`/`ext`/`syntax`.
 
 ### P4 — trivial
 - [x] **R16** `ftplugin/vimwiki.vim` header comment says `ftplugin/nuwiki.vim`.