fix(cli): allow generic file uploads through buzz messages send --file

[TechPrieto]

Summary

buzz-cli's upload_file() rejected any MIME type outside a narrow image/video allowlist before the file ever reached the relay. The relay's /upload endpoint already routes non-image/video bytes through buzz_media::process_file_upload — a generic-file path with its own magic-byte sniffing, size cap, and deny-list for active-content/executable types (buzz-media/src/validation.rs) — so the CLI's stricter local check was purely redundant and blocked legitimate attachments (docs, text, PDFs, archives) that the server already supports.

• Replace the CLI's local allow-list with a deny-list mirroring the relay's BLOCKED_FILE_MIME_TYPES; anything else now uploads and lets the relay be the authoritative validator, as already happens for images.
• Fix the markdown embed for non-image/video uploads: they were rendered as broken ![image](url) embeds. Desktop's resolveFileCard renderer expects a markdown link ([filename](url)) plus the imeta MIME to show a generic-file download card, so route those through a [filename](url) link using the original filename (Blossom URLs are content-hash-addressed, not human-readable).

Test plan

• cargo test -p buzz-cli — 321/321 passing, including 4 new unit tests for the markdown formatting helper
• Live end-to-end test against a production relay: uploaded a .txt and a .zip via buzz upload file and buzz messages send --file, confirmed the resulting message renders a working generic-file download link

🤖 Generated with Claude Code