fix: resolve path-style wikilinks on Windows backslash paths (#885)

[thfaix]

Summary

Path-style wikilinks ([[folder/note]]) silently fail to resolve on Windows — clicking the link does nothing.

resolveEntry's Pass-1 findEntryByPathSuffix (src/utils/wikilink.ts) compared entry.path against path suffixes built with forward slashes (/folder/note.md):

entry.path.toLowerCase().endsWith(pathSuffix)

But entry.path carries OS-native separators — on Windows it's produced by path.to_string_lossy() in src-tauri/src/vault/mod.rs, so it uses backslashes (folder\note.md). A backslash path never .endsWith() a forward-slash suffix, so the path-suffix pass never matched on Windows. Links then either fell through to the filename-stem pass (resolving to the wrong note when two notes share a filename across folders) or failed entirely, leaving the click dead.

This is the ADR-0035 "Obsidian-style, zero-config path-suffix resolution" feature breaking on Windows.

Fix

Normalize entry.path with the existing normalizeFilesystemPath helper (already used by relativePathStem) before the endsWith comparison — a one-helper change that brings path-suffix matching in line with the rest of the module.

Tests

Added two regression tests in src/utils/wikilink.test.ts covering Windows backslash entry paths, including the subfolder-disambiguation case the filename-stem fallback could not mask. Followed the repo's TDD process (red → green).

Verified locally:

• pnpm exec vitest run — 4461 passed (407 files)
• npx tsc --noEmit — clean
• npx eslint src/utils/wikilink.ts src/utils/wikilink.test.ts — clean

I could not run the native pre-push lane locally (Playwright smoke / cargo / CodeScene PAT-gated steps); leaving those to CI.

Repro

1. Open a vault with subfolders on Windows 11 (Tolaria 2026.6.10).
2. Add [[folder/note]] linking to a note in a subfolder.
3. Click it → before this fix, nothing happens (DevTools shows Navigation target not found: folder/note); after, the target note opens.

Fixes #885