REST API attachment content upload broken in v0.26.2 (local filesystem storage)

[smallmj]

Description

After upgrading to v0.26.2, I can no longer upload file attachments via the REST API. The frontend UI upload works perfectly fine, but all REST API approaches fail.

Steps to reproduce

1. Set storage mode to 'Local filesystem' (path: /var/opt/memos/uploads)
2. Via REST API, try to create an attachment with content:

POST /api/v1/attachments
Body: {"filename": "test.png", "type": "image/png", "content": "<base64>"}

3. Response returns 200 with attachment created, but content and size fields are empty
4. Same result using PATCH to update content:

PATCH /api/v1/attachments/{id}
Body: {"content": "<base64>"}

Returns 200 but content remains empty

Expected behavior

• REST API should allow uploading file content and serve it via /o/attachments/{id} or similar path
• size field should reflect actual file size, not 0

Actual behavior

• Attachment metadata created successfully, but file content cannot be stored via REST API
• Frontend UI upload works (files are stored and accessible), confirming storage is configured correctly
• All file access paths (/o/attachments/{id}, /r/{id}, etc.) return the Memos SPA HTML page, not actual file content
• This breaks all programmatic/CLI attachment upload workflows

Environment

• Memos version: 0.26.2
• Storage mode: Local filesystem (/var/opt/memos/uploads)
• Docker deployment
• Volume mapping: confirmed working (container /var/opt/memos mapped to host path)
• Frontend upload works → storage and permissions are NOT the issue

REST API test results

Endpoint	Method	Result
/api/v1/attachments	POST with content	200, attachment created, size populated correctly, but content field empty and file inaccessible
/api/v1/attachments/{id}	PATCH with content	200, content remains empty, size=0
/o/attachments/{id}	GET	Returns HTML (Memos SPA), not the actual file
/r/{id}	GET	Returns HTML (Memos SPA), not the actual file

Additional notes

• Frontend UI upload creates attachments that show correct size (e.g. 237337 for a real JPEG) and presumably work fine
• The bug appears to be in the REST gateway's handling of binary content — the gRPC/Connect RPC path used by the frontend works fine, but the REST proxy does not properly handle file content uploads
• This breaks all third-party tools, CLIs, and programmatic workflows that rely on the REST API for file uploads (e.g. memos-cli, Python scripts, etc.)