fix(links): strip subpaths when resolving link targets

[michaelpporter]

Refs #734 — intentionally not an auto-closing keyword; the issue is closed when the fix ships in a release.

Stacked on #737 — this PR targets the #731 branch, so its diff shows only the subpath change. GitHub will retarget it to main automatically once #737 merges.

Problem

down:: [[2#^71f2d9]] in 1.md resolved to a phantom 2#^71f2d9.md node. Node identity in the WASM graph is the resolved path string, so 2.md and 2#^71f2d9.md are two different nodes — the down→up transitive rule hung the reverse edge off the phantom.

That produces exactly the asymmetry reported: 1.md's tree renders fine, while 2.md never shows 1.md as its parent.

Root cause: resolve_relative_target_path passed the raw link text to getFirstLinkpathDest, which rejects anything carrying a #subpath, so the link fell through to the unresolved-path fallback.

Fix

Strip everything from the first # before resolving. # is illegal in vault filenames, so the first one always starts a subpath.

This is a single chokepoint — it fixes both typed_link passes (frontmatter and inline) and list_note, which had the same latent bug, and works regardless of which folders the notes live in.

A subpath-only link ([[#^71f2d9]]) points into the source note itself, so it now yields no edge rather than a self-loop.

Tests

bun run build && bun run test pass (379 tests, 0 type errors).

New tests/utils/obsidian.test.ts. The mock's getFirstLinkpathDest returns null for anything containing #, matching the real API — that's what makes these tests meaningful rather than tautological. Covers: block ref, heading ref, cross-folder block ref, block ref to a non-existent note, subpath-only link, and .canvas#group.