Render clickable Supernote internal links in SupernoteView

[philips-clanker]

Closes #127.

Summary

Renders each page's Supernote internal links (ILink/sn.links, parsed since #121's submodule bump) as a clickable overlay in SupernoteView:

• Overlay rendering: LINKRECT regions are positioned/scaled using the exact same mechanism (drawPageImage()) that already keeps the pdf.js text layer aligned through zoom — a new .supernote-links-layer sits alongside the existing .textLayer, sized identically, carried along by the same CSS transform during a zoom drag.
• Same-file links jump to the target page in place via the existing goToPage(), resolving PAGEID against the currently-loaded file's own pages.
• Cross-file links resolve their target by basename against the vault, mirroring VaultWriter.resolvePageAnchor()'s export-time link resolution from Export Supernote keywords as tags and links as Wikilinks #122 (so a link resolves to the same note whether you're viewing it live or exporting it), then open it via a new leaf using the existing #page=N ephemeral-state anchor — the same mechanism a regular [[note#page=N]] link already uses — rather than inventing a new cross-view API.
• If the target note isn't in the vault, shows a Notice rather than failing silently or (Obsidian's default openLinkText behavior) creating an empty note.

parseLinkRect/bucketLinksByPage live in a new Obsidian-free module (src/linkOverlay.ts) so they're unit-testable — main.ts extends several Obsidian base classes and has never had test coverage as a result. Includes a test that loads the submodule's own real link-tag fixture (nomad-3.26.40-link-tag-3p.note) and checks LINKRECT decodes to values within [0, pageWidth] x [0, pageHeight], concretely verifying the coordinate-space assumption the overlay math depends on instead of trusting it from a doc comment.

This is the first test in the repo that reads a real file from disk, which needed some plumbing: vitest.config.ts now aliases supernote-typescript to the submodule's compiled lib/ (mirroring tsconfig.json/esbuild.config.mjs), and a small src/node-shims.d.ts gives fs/path/import.meta.dirname narrow ambient types without pulling in all of @types/node — doing that project-wide collides with the DOM lib's Window.setTimeout typing that deviceFetch.ts/main.ts already rely on (window.setTimeout's return type goes ambiguous between DOM's number and Node's NodeJS.Timeout once both are in scope).

Scope decisions

• SupernoteEmbed (the simpler, separate embed renderer) is out of scope — Clickable links in SupernoteView? #127 asks specifically about SupernoteView.
• No modifier-click (Ctrl/Cmd) to open cross-file links in a new pane — no existing precedent for Keymap.isModEvent in this codebase; v1 always reuses the current-most-recent leaf.
• Basename-based cross-file resolution is ambiguous if two vault notes share a basename in different folders — same known limitation Export Supernote keywords as tags and links as Wikilinks #122 already accepted for the export path.

Test plan

• npx vitest run — 32 passed (including the 10 new linkOverlay.test.ts cases)
• npx tsc --noEmit --skipLibCheck — clean
• npx eslint src/main.ts src/linkOverlay.ts src/linkOverlay.test.ts src/node-shims.d.ts — clean
• npm run build — clean
• Manual test in Obsidian against real device link data — not possible in this environment (no Supernote hardware); the fixture-based test is the closest available verification. Would appreciate a real-device smoke test before merge.

[philips-clanker]

Pushed a fix for a real bug found while testing against an actual note with two internal links: nothing rendered at all.

Root cause was two stacked mistakes in `bucketLinksByPage`:

• Filtering to `LINKTYPE === '1'` dropped both real links in the test note (their `LINKTYPE` was `'0'`) — the doc comment claiming `1 = internal note link` doesn't hold up against real data.
• Using `ILink.OBJPAGE` for the source page looked right but isn't — verified by drawing each link's `LINKRECT` onto every rendered page of the test note and measuring ink coverage under it. `OBJPAGE` (4 and 1) didn't match either link's actual page (array index 0 and 3) under any indexing convention; it tracks something else, closer to the page's own template label than its current array position.

Reverted to the original `sn.links` key-prefix convention (1-indexed page in the key's first 4 characters, from PR #122) — that turned out to be correct all along. It only looked broken against the submodule's own link-tag test fixture because all three of that fixture's links happen to share one page and one key prefix, which I mistook for evidence the key was meaningless. Re-verified with an exact expected-bucketing assertion against that fixture, not just "some valid page index" like before.