[Bug]: attachments in the attachment folder are never auto-committed

[matthiasautrata]

Summary

New files under the attachment folder (content.attachmentFolderPath, e.g. ./assets) are never picked up by auto-save/auto-sync. A note that references a freshly pasted/dropped image gets auto-committed with the reference, but the image itself stays untracked/uncommitted until a user manually git adds it.

Steps to reproduce

1. In a project with content.attachmentFolderPath: ./assets set in .ok/config.yml, paste or drag an image into a note.
2. Let auto-save run (or wait for the normal debounce/sync cycle).
3. git log -- assets/ — no commit ever touches the file.
4. git status shows the image sitting as untracked (or manually staged) while the note's own auto-save commits land normally.

Evidence

• Every historical Auto-save: ... commit in my vault touches only .md files — grepping the full commit history for changes under assets/ returns nothing, going back to the initial commit.
• Desktop log (~/.ok/logs/desktop.*.log) shows the sync/CRDT pool (ok-pool-recycle-*, [syncPromise] ...) is keyed entirely by docName (e.g. notes/Foo) — there is no equivalent tracking for paths under the attachment folder.

Expected behavior

Either:

• New/changed files in the attachment folder are included in the same auto-save commit as the note(s) that reference them, or
• Auto-save surfaces a warning when a saved doc references a local attachment that isn't yet tracked/synced, so users aren't left with silently-unsynced media.

Actual behavior

Attachments are written straight to disk outside the CRDT/journal layer and are completely invisible to auto-sync. A note can be "saved" while an image it references is not actually backed up anywhere, with no indication this happened.

Environment

• OpenKnowledge Desktop
• .ok/config.yml: content.attachmentFolderPath: ./assets, content.dir default (.)