fix(export): resolve wikilink images during PDF exports

[Abhiraj1401]

Fix wikilink image rendering in PDF exports

Summary

Fixes PDF exports rendering embedded wikilink images such as ![[image.png]] as raw text instead of images.

Both desktop and web PDF export pipelines now preprocess wikilink image embeds into standard Markdown image syntax before passing the note to the existing preview renderer.

Changes

• Applied the existing shared rewriteWikilinkImageEmbeds preprocessor in the desktop PDF export window.
• Applied the same preprocessing in the web PDF export window.
• Reused the existing vault-aware asset resolution pipeline instead of introducing duplicate path-resolution logic.
• Preserved support for:
  • filenames containing spaces
  • nested asset paths
  • alt text
  • width and dimension hints
  • missing assets without crashing the export
• Added regression tests for nested paths, spaces, alt text, dimension parameters, and missing files.
• Left normal note preview behavior and unrelated export functionality unchanged.

Examples

The PDF pipeline now converts wikilink image embeds such as:

![[image.png]]
![[subfolder/team photo.png|Team photo]]
![[image.png|300]]
![[image.png|Quarterly chart|600x400]]

into standard Markdown image nodes before rendering:

![](image.png)
![Team photo](<subfolder/team photo.png>)
![|300](image.png)
![Quarterly chart|600x400](image.png)

The existing asset resolver then maps each image target to the appropriate vault-relative asset URL. It supports note-relative paths, vault-root paths, and unique filename matches.

If an asset is missing, the export continues without throwing and retains the image's fallback alt text.

Testing

• Focused PDF/wikilink regression tests: 81 passed
• Load-sensitive full-suite tests rerun in isolation: 106 passed
• Shared-domain typecheck: passed
• App-core typecheck: passed
• Desktop typecheck: passed
• Web typecheck: passed
• git diff --check: passed
• Manual verification on Fedora Linux: passed

The full parallel monorepo test run initially reported four unrelated load-sensitive failures, including two timeouts. All four passed when rerun together in isolation.