fix(html): emit heading id anchors so exported #links resolve

Exported HTML anchor links (TOC entries, [[Page#Heading]], [[#Heading]])
went nowhere because heading elements carried no `id`. Worse, the two TOC
builders slugified anchors (`#my-heading`) while the link resolver emits
the raw heading text (`#My Heading`, matching upstream vimwiki), so even
once ids existed the two halves wouldn't have agreed.

Fix — adopt vimwiki's scheme (raw heading text as the anchor) everywhere:
- render_heading emits `<hN id="<plain heading text>">`.
- build_toc_html (HTML export TOC) uses the raw, HTML-escaped title for
  both the href and the link text (was slugify).
- collect_toc_items (:VimwikiTOC buffer output) uses the raw title for the
  generated `[[#anchor]]` (was slugify). In-editor navigation slugifies
  both sides, so it still resolves.

Consistency: add canonical `nuwiki_core::ast::inline_text()` and route the
heading id, the HTML-TOC title, the buffer-TOC title, and
`diagnostics::heading_text` through it — three duplicated extractors
collapsed into one, so the anchor and its validation can't drift.

Regression test: heading_id_matches_anchor_link_href (core) asserts the
heading id and a `#anchor` link's href are identical. Updated the heading
assertions in the renderer/export tests for the new `id=` attribute.

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

crates/nuwiki-core/src/render/html.rs

@@ -319,7 +319,13 @@ impl HtmlRenderer {
         } else {
             ""
         };
-        write!(w, "<h{level}{class}>")?;
+        // `id` is the heading's plain text (vimwiki's anchor scheme), so
+        // `[[Page#Heading]]` and TOC `#Heading` links land here. Matches the
+        // anchor text the LSP validates and the resolver emits.
+        let anchor = crate::ast::inline_text(&n.children);
+        write!(w, "<h{level}{class} id=\"")?;
+        write_escaped(&anchor, w)?;
+        write!(w, "\">")?;
         if !number.is_empty() {
             write_escaped(number, w)?;
         }