fix(follow-link): resolve+open definitions ourselves on the Vim clients

The Vim follow-link path delegated to the LSP client's jump UI
(:LspDefinition / coc jumpDefinition), which broke two ways for wiki
link-following:

1. **No create-on-follow (vim-lsp + coc).** vim-lsp's location handler
   readfile()s the target to build a quickfix entry; for a not-yet-created
   page that throws E484 and aborts the jump, so <CR> on [[NewPage]] did
   nothing. The server was correct throughout — textDocument/definition
   returns a *synthesised* location for missing pages (verified over
   JSON-RPC).
2. **Wrong window placement (coc).** Without an explicit open command coc
   fell back to coc.preferences.jumpCommand (e.g. a tab command).

Stop delegating: nuwiki#commands#follow_link_or_create() /
follow_link_drop() now resolve textDocument/definition directly and open
the URI themselves via a shared s:open_definition(open_cmd) helper — :edit
for <CR>, `tab drop` for <C-S-CR>. :edit opens a buffer for a missing path
(save creates it, matching vimwiki) and gives exact current-window
placement regardless of the user's coc jumpCommand. Removes
s:jump_definition / s:drop_from_response.

Also fix the coc action name: CocAction('getDefinition') does not exist
(E605 "Action getDefinition does not exist") — the registered action is
'definitions'. Fixed in s:open_definition and badd_link.

coc config delivery: the setup guidance shipped without
initializationOptions, so coc users never sent wiki_root and the server
resolved links against its default root (existing pages flagged broken,
follow-to-create landed in the cwd). The printed snippet
(autoload/nuwiki/lsp.vim) now emits initializationOptions populated with
the resolved settings, and the README coc snippet documents it as required.

Add development/start-vim-coc.sh — a coc.nvim dev launcher (sibling of
start-vim.sh) that wires coc's prebuilt release branch + a generated
coc-settings.json (with initializationOptions), deliberately omitting
vim-lsp so the coc path is exercised; doubles as a reproducer.

Tests: new cr.follow_opens_missing_page_in_current_window case in
test-keymaps-vim.vim (stubs CocAction to a missing page, asserts
current-window :edit). Keymap suite 254+18 green; config-parity (Vim +
Neovim) green. Neovim path unchanged and re-confirmed.

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

development/vimwiki-gap.md

@@ -44,29 +44,40 @@ fix site.
 
 ## Regressions (reported by users — verify, then fix)
 
-- [ ] **`<CR>` link-follow opens a new tab instead of reusing the current
-  window** — pressing `<CR>` on a link used to open the target in the *same*
-  tab/window the user was browsing in (upstream behavior). It now opens a
-  **new tab and switches to it**. Reported on Vim 9.x + Dein.
-  _Investigation so far:_ the nuwiki `<CR>` path is **unchanged** by the recent
-  P1 #1/#2/#3 work — `git blame` shows the `<CR>` map (`ftplugin/vimwiki.vim`
-  Vim branch `:206`, Neovim branch `lua/nuwiki/keymaps.lua:161`) and the
-  `follow_link_or_create` → jump-definition chain were not touched; only
-  `<C-S-CR>` was repointed to `follow_link_drop()` in `f65d861`. Both client
-  jump paths open in the current window by default
-  (`vim.lsp.buf.definition()` with no opts; Vim `s:jump_definition()` →
-  `LspDefinition`, `autoload/nuwiki/commands.vim:73`), so the new-tab behavior
-  is **not** coming from nuwiki's own placement logic as written.
-  _Rule out first (env, per memory):_ a **stale dein copy** of the plugin
-  (`bin/nuwiki-ls` + copied ftplugin) and a **double `rtp` entry** where the
-  upstream vimwiki bundle is still loaded alongside nuwiki — either can shadow
-  the `<CR>` map or pull in upstream/`LspDefinition --tab`-style behavior.
-  Recache dein + rebuild + restart LSP and confirm only nuwiki's ftplugin is
-  active before treating this as a nuwiki code bug.
-  _Suspected sites if it reproduces clean:_ vim-lsp's definition-open default
-  (Vim) and the `vim.lsp.buf.definition()` handler (Neovim) — pin which `<CR>`
-  press (bare-word wrap vs. existing-link follow) triggers the tab and whether
-  the server's definition response shape steers placement.
+- [x] **`<CR>` link-follow: wrong window placement + no create-on-follow on the
+  Vim clients** — two related Vim-branch bugs (Neovim path was already correct):
+  (a) on coc.nvim, `<CR>` opened the target in a **new tab** instead of the
+  current window; (b) on **both** vim-lsp and coc, `<CR>` on a link to a
+  not-yet-created page **failed to open/create it**.
+  _Root cause:_ the Vim follow path delegated to the LSP client's jump UI
+  (`:LspDefinition` / `CocActionAsync('jumpDefinition')`). Those fetch the
+  target's text before jumping — vim-lsp `readfile()`s it for the quickfix entry
+  (`autoload/lsp/utils/location.vim`), which throws `E484` for a missing file
+  and aborts the jump (→ no create-on-follow); coc, lacking an explicit open
+  command, fell back to the user's `coc.preferences.jumpCommand` (→ new tab).
+  The server itself was correct throughout — verified over JSON-RPC that
+  `textDocument/definition` returns a *synthesised* location for missing pages
+  and resolves existing links.
+  _Fix:_ stop delegating. `nuwiki#commands#follow_link_or_create()` /
+  `follow_link_drop()` now resolve `textDocument/definition` directly and open
+  the URI ourselves via a shared `s:open_definition(open_cmd)` helper
+  (`autoload/nuwiki/commands.vim`) — `:edit` for `<CR>`, `tab drop` for
+  `<C-S-CR>`. `:edit` opens a buffer for a missing path (save creates it,
+  matching vimwiki) and gives exact current-window placement regardless of the
+  user's coc jumpCommand. Covered by
+  `cr.follow_opens_missing_page_in_current_window` in
+  `development/tests/test-keymaps-vim.vim`; manually reproducible via
+  `development/start-vim.sh` (vim-lsp) and `development/start-vim-coc.sh` (coc).
+- [x] **coc.nvim reported valid links as broken / couldn't resolve** — only via
+  the new `development/start-vim-coc.sh` launcher: its generated
+  `coc-settings.json` registered the server with `command`/`filetypes` but no
+  `initializationOptions`, so `wiki_root` never reached the server and it
+  resolved links against its default (`~/vimwiki`). _Fix:_ the launcher now
+  emits `initializationOptions` **and** `settings.nuwiki` mirroring the vim-lsp
+  client (`autoload/nuwiki/lsp.vim` `s:settings()`). Verified with a headless
+  coc.nvim run: `[[Notes]]` resolves, only genuinely-missing links warn. (Shipped
+  plugin only — no production code change; coc users configure their own
+  `coc-settings.json` per the README snippet.)
 
 ## P2 — Moderate (real users hit these)