feat(config): vimwiki drop-in config + global per-wiki defaults

Two related config-ergonomics features for vimwiki migrants, sharing the
same scalar-global machinery.

1. Upstream g:vimwiki_* drop-in (Vim client). When nuwiki isn't configured
   natively, the Vim client reads g:vimwiki_list + g:vimwiki_* globals and
   translates them into nuwiki's schema: per-wiki path->root,
   path_html->html_path, template_*, css_name, auto_export/auto_toc,
   syntax, ext->file_extension, index, diary_*, name. g:nuwiki_* always
   wins. Lets a vimwiki user drop in nuwiki without rewriting config.

2. Global per-wiki defaults (both clients). A display/generation setting
   given once at the top level — g:nuwiki_<key> / setup({<key>=…}) /
   g:vimwiki_<key> — is folded into every wiki as a default; a per-wiki
   value overrides it (vimwiki's model). Covers toc_header(_level),
   toc_link_format, links_header(_level), tags_header(_level),
   html_header_numbering(_sym), links_space_char, list_margin, listsyms,
   listsym_rejected, and the auto_* toggles. Only values the user
   explicitly set fold — built-in defaults don't (added config.user
   tracking on the Lua side so a default toc_header_level=1 isn't pushed
   onto every wiki). User config tables are never mutated.

Both clients kept in lock-step (config-parity golden enforces identical
payloads). New harnesses test-vimwiki-compat-vim (18) and
test-global-shorthand (8), wired into CI. Server test
vimwiki_compat_payload_sets_toc_level_per_wiki. Docs in README +
known-issues.md (drop-in is currently Vim-only). Rust 573 passed, clippy
clean, all harnesses green.

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

README.md

@@ -337,6 +337,14 @@ The `<Leader>w` prefix in the `wiki_prefix`, `links`, and `html_export` rows is
 
 #### Per-wiki keys (`wikis[]`)
 
+Most display/generation keys below can also be set **once at the top level**
+as a default for every wiki (vimwiki-style global shorthand) — via `setup({ … })`
+or `g:nuwiki_<key>` — and a per-wiki value overrides it. The keys that honour
+this are `toc_header`, `toc_header_level`, `toc_link_format`, `links_header`,
+`links_header_level`, `tags_header`, `tags_header_level`,
+`html_header_numbering`, `html_header_numbering_sym`, `links_space_char`,
+`list_margin`, `listsyms`, `listsym_rejected`, and the `auto_*` toggles.
+
 | Key | Type | Default | Accepted values |
 |-----|------|---------|-----------------|
 | `name` | string | — | any label |
@@ -660,8 +668,18 @@ match vimwiki. To migrate:
 
 1. Drop the original `vimwiki` plugin from your config.
 2. Install nuwiki.
-3. Point `wiki_root` (or each `wikis[i].root`) at your existing
-   directory.
+3. Keep your existing config, or point `wiki_root` / `wikis[i].root` at
+   your directory.
+
+**Existing `g:vimwiki_list` config works as-is (Vim).** When you haven't
+configured nuwiki natively (`g:nuwiki_wikis` / `g:nuwiki_*`), the Vim
+client reads your upstream `g:vimwiki_list` and `g:vimwiki_*` globals and
+translates them: each wiki's `path`/`path_html`/`template_*`/`auto_export`
+plus globals like `toc_header_level`, `html_header_numbering`,
+`html_header_numbering_sym`, `links_space_char`, and `list_margin`.
+Native `g:nuwiki_*` config always takes precedence. (Settings nuwiki
+implements differently — see [`known-issues.md`](./known-issues.md) — are
+ignored.)
 
 Existing pages, diary entries, tags, and templates work without
 modification. The first workspace scan after launch may show an empty