fix(graph): decode location.pathname before using it as the local-graph slug

[isle-blu]

Fixes #2

Root cause

getSlugFromUrl() derives the current page's slug from window.location.pathname via getFullSlugFromUrl(), but never decodes it. Browsers keep pathname percent-encoded for non-ASCII/reserved characters, so for any slug containing them (CJK, {}, etc.) this local-graph-only seed slug never matches the already-decoded keys in the fetched content index / link list.

Two visible symptoms follow from that single mismatch:

1. data.get(url)?.title misses for the current page's own node, so the label falls back to the raw, still-encoded url — the garbled/mojibake-looking text reported in Local graph fails on pages with encoded characters in the URL #2.
2. The BFS neighbourhood walk also keys off this same broken slug, so none of the (correctly-normalized) link.source/link.target pairs ever match it — the node renders with no visible edges, even though it does have backlinks.

The global graph is unaffected because its neighbourhood construction (depth < 0) walks the already-normalized link keys directly instead of seeding from the current page's slug.

Fix

Decode the pathname once, at the source, in getSlugFromUrl(), guarded with try/catch so a malformed escape sequence (e.g. a literal % not part of a valid encoding) falls back to the raw value instead of throwing.

Testing

• npm run check (typecheck/lint/format/vitest) and npm run build pass locally; dist/ in this PR matches a fresh build.
• Manually reproduced and verified fixed with:
  • Korean note titles/links (percent-encoded multi-byte UTF-8)
  • The {Foo} / {Foo} case from Local graph fails on pages with encoded characters in the URL #2

Both now render the correct label and correct edges in the local graph.

[isle-blu]

Closing in favor of #5, which fixes the same root cause.