Fix attachment link resolution with org-attach ID-based storage

[jwiegley]

Summary

Fixes #1073

This PR fixes an issue where gptel does not correctly locate media files referenced by org-mode "attachment" links when using org-attach's ID-based storage support.

Changes

1. gptel-org.el (gptel--parse-media-links)

• Use org-attach-expand to properly resolve attachment-type links to their actual file paths
• This is necessary when org-attach uses ID-based storage where attachment directories are not relative to the current file
• Added declare-function for org-attach-expand

2. gptel-request.el (gptel--realize-query)

• Call gptel--parse-buffer in the original buffer context rather than the temp buffer
• This ensures org-attach-expand has access to Org properties (ID, ATTACH_DIR) needed to resolve attachment paths
• These properties are not copied to the temp buffer, so the context switch is necessary

Testing

• Backward compatible: file-type links continue to work as before
• Attachment-type links now properly expand to absolute paths when using ID-based storage
• Existing test suite validates media link parsing functionality

Test plan

1. Customize org-attach-id-dir to a location outside the working directory
2. Create an Org file with a heading that has an ID property
3. Attach an image file to the heading using org-attach
4. Link to the attachment using [[attachment:filename.png]]
5. Enable media tracking in gptel
6. Send a query asking about the image
7. Verify the image is correctly encoded and sent to the LLM

Without this fix, the LLM would not receive the image. With the fix, the image is properly encoded and included in the request.

🤖 Generated with Claude Code

[jwiegley]

I tested this in the debugger by hand with a chat file as described by the original reporter, and indeed without these changes it was not able to see my attached image, but with the changes it saw it correctly and added it to the prompt to be sent.