Garbage collection for unreferenced attachments

Follow up to #1623 and #1633.

Since #1633, API attachments live in a note's own .attachments. folder. The whole folder is removed when the note is deleted, and a single file can be removed through the new DELETE attachment endpoint. What is still missing is cleanup of attachments that are no longer referenced in a note's text.

When a user edits a note and removes an image or a link, the underlying file stays in .attachments. indefinitely, so orphaned files build up that nobody can reach from the note.

This was left out because finding unused attachments means parsing each note's Markdown to collect the referenced paths, which is the server side parsing we have tried to avoid for sync performance. So it needs a deliberate approach.

Options to consider:

• On note save, parse the referenced paths and delete any file in that note's .attachments. folder that is no longer referenced.
• A separate background or on demand job that does the same sweep across all notes.
  Leave deletion to clients through the DELETE endpoint and keep nothing automatic.

Open questions: which trigger is acceptable given the sync performance concern, and how to treat attachments referenced by relative paths that point outside the note's own folder.

Start by reading the context in issues #1623 and #1633 and the existing DELETE attachment endpoint. The issue presents several possible cleanup triggers but does not choose one; first determine an acceptable approach for parsing note Markdown without harming sync performance and define handling for relative paths outside the note folder. Done means an agreed, implemented cleanup strategy with its edge cases addressed.