fix(wiki): portable relative markdown links so wiki navigation works outside Obsidian

[TPAteeq]

Closes #1444.

graphify export wiki (to_wiki) wrote articles with Obsidian-style [[Title]]
wikilinks. Two defects made nearly every navigation link dead outside Obsidian:

1. Convention mismatch. [[Title]] resolves by note title only inside
   Obsidian. Everywhere else — VS Code preview, GitHub, GitLab, a plain browser —
   [[Domain Data Models]] resolves to a literal Domain Data Models.md, but the
   article file is Domain_Data_Models.md (the slug replaces spaces with
   underscores and substitutes reserved characters). The reporter measured one real
   run: index + 38 articles, 206 [[...]] links, 108 of them community/god-node
   navigation links — all broken outside Obsidian.
2. Dead links. God-node articles linked every neighbor ([[AwsHelper.py]],
   [[.read_object_key()]]), but only communities and god nodes get article files —
   so those ~98 node-level links were dead even inside Obsidian.

Fix

Emit standard relative markdown links [display](slug.md) instead of [[...]],
with the target URL-encoded via urllib.parse.quote so spaces, &, parentheses,
and # survive intact in every CommonMark renderer and in Obsidian (which resolves
standard relative links and still shows them in graph view / backlinks). Links
whose label has no article render as plain text instead of a dangling link.

To make the link target always match the file actually written, to_wiki now
assigns every article its slug in a first pass (building a label -> slug
resolver) before rendering any body — so a link tracks the on-disk filename
including any numeric collision suffix (parser_2.md). Slug-assignment order
(communities, then god nodes) is unchanged, so the case-fold collision dedup keeps
producing identical filenames.

This is the portable-links option from the issue; I left the alternative
--obsidian-style flag out to keep the change focused — standard links already
work in Obsidian, so nothing is lost there, and a flag is easy to add later if
anyone wants [[...]] back.

Testing

• Updated the existing test_wiki.py cases that asserted the old [[...]] form to
  assert the new [display](slug.md) form.
• New regression tests: no file contains [[...]]; every inline link target across
  the whole wiki resolves to a real file on disk; display text keeps the human
  label while the target is the underscored filename; special characters (space,
  &, #, parens) round-trip through URL-encoding to the real file; node-level
  links to article-less neighbors are plain text; and links to a collision-suffixed
  article target the suffixed slug. All red on the pre-fix code, green after.
• Full suite: 2423 passed, 2 skipped.

Out of scope

Two pre-existing label-ambiguity edge cases (two communities with an identical
label collapse to one link target and orphan the second article; a community
literally labelled index collides with index.md) are not introduced or worsened
here — the old [[...]] form was equally ambiguous — so I left them for a separate
change to keep this PR scoped to the reported bug.

[safishamsi]

Thanks @TPAteeq — this is the correct fix for #1444 (standard [display](slug.md) links, URL-encoded, resolving in every renderer). Landed on v8 in ec5bb33 with your authorship. Minor maintainer edit: trimmed the CHANGELOG wording that said the target "always" matches the written file — two articles with a byte-identical label still keep the first slug (pre-existing, same as the old [[label]]), so I scoped the claim to the case-fold collision case. Verified end-to-end: no [[..]] emitted, links URL-encode and resolve to real files. Closing as merged-by-port.