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>

README.md

@@ -155,7 +155,12 @@ on your behalf, so add the entry once yourself (open it with
   "languageserver": {
     "nuwiki": {
       "command": "~/.vim/pack/gffranco/start/nuwiki/bin/nuwiki-ls",
-      "filetypes": ["vimwiki"]
+      "filetypes": ["vimwiki"],
+      "initializationOptions": {
+        "wiki_root": "~/vimwiki",
+        "file_extension": ".wiki",
+        "syntax": "vimwiki"
+      }
     }
   }
 }
@@ -163,9 +168,18 @@ on your behalf, so add the entry once yourself (open it with
 
 Point `command` at the installed binary — by default it lives in the
 plugin's `bin/` directory (adjust the path for your plugin manager), or
-set `g:nuwiki_binary_path` and reuse that value. With coc you can also
-invoke server commands directly via `:CocCommand nuwiki.<command>`
-instead of the `:Vimwiki*` / `:Nuwiki*` aliases.
+set `g:nuwiki_binary_path` and reuse that value.
+
+`initializationOptions` is **required** — it carries `wiki_root` (and the
+other [config keys](#configuration)) to the server, exactly as the vim-lsp
+registration does automatically. Without it the server resolves links
+against its default root, so existing pages show up as broken links and
+following a link to a new page creates it in the wrong directory. (Run
+`:NuwikiInstall`-time guidance, or `:call nuwiki#lsp#start()` once, to have
+nuwiki print this snippet with your configured paths already filled in.)
+With coc you can also invoke server commands directly via
+`:CocCommand nuwiki.<command>` instead of the `:Vimwiki*` / `:Nuwiki*`
+aliases.
 
 ### Try it without touching your config