fix: percent-encode attachment filenames in image links

[blaipr]

Problem

download wrote attachment names raw into image links: an attachment called my file (1).png became ![a](Page_attachments/my file (1).png), which every standard Markdown renderer (CommonMark, GitHub, editor previews) reads as a link target ending at the first space — the image does not render. In the other direction, a link written the standard way by hand (![a](img/my%20file.png)) was taken literally: ri:filename="my%20file.png" went into the page and attach_local_images looked for a file literally named my%20file.png, reported it missing, and left a broken attachment reference.

Python-Markdown happens to accept spaces inside link targets, so the tool's own round trip masked both problems.

Change

• Storage → Markdown: the filename is quote()d in the link target (my%20file%20%281%29.png); the alt text is unchanged.
• Markdown → storage: the image src is unquote()d before it is used as the attachment filename and collected for attach_local_images.
• download_page decodes the names it extracts from the links before matching them against the page's attachments and writing them to disk.

Compatibility

Links without spaces or special characters are unchanged in both directions. Markdown files downloaded before this change (raw spaces) still upload correctly, since unquote() leaves them alone.

Checklist

• ruff check src tests, ruff format --check src tests and python -m pytest tests/ pass
• Tests added for the change (tests/test_images.py)
• Docs updated (docs/conversion.md, Images)
• docs/conversion.md updated because an equivalence changed
• CHANGELOG.md updated under Unreleased