`buzz messages send --file` embeds every non-video attachment as ``, so documents arrive as broken images

**Describe the bug**

`buzz messages send --file ` builds the markdown embed from a two-way
branch: `video/*` gets ``, and **everything else** gets ``.
There is no branch for "not displayable inline".

`crates/buzz-cli/src/commands/messages.rs:658-665` (on `main` @ `b1f6b7ef7`):

```rust
media_tags.push(crate::client::build_imeta_tag(&desc));
if desc.mime_type.starts_with("video/") {
media_content.push_str("\n![video](");
} else {
media_content.push_str("\n![image](");
}
media_content.push_str(&desc.url);
media_content.push(')');
```

So a `.txt`, `.pdf`, `.md` or `.xlsx` is announced to the client as an image.
Buzz Desktop renders a broken-image placeholder, and clicking it opens the image
viewer — empty, with a zoom bar under it. The file itself uploaded fine and the
`imeta` tag is correct; only the message body is wrong.

**This is not a client limitation.** #6791 describes the intended baseline for
these types as "a generic file card with a download button". The client can show
that already — the CLI just talks it out of it by putting an image embed in the
body.

**Why "name it with the right extension" is not a workaround**

The relay types a blob by **sniffing content**, not by filename (`infer::get()`,
`buzz-media/src/validation.rs`). Plain text has no magic signature, so it is
stored as `application/octet-stream` however the file is named. Measured on
relay 0.2.1:

```
$ buzz upload file --file test-atasament.txt
{
"url": "https:///media/e9cb2c16….bin",
"size": 40,
"type": "application/octet-stream"
}
```

The upload is `.bin` / `application/octet-stream`, and the branch above then
sends it as `![image]`. Every text document takes this path.

**To Reproduce**

1. `printf 'hello\n' > note.txt`
2. `buzz messages send --channel --file note.txt --content "test"`
3. Read the event back — the body ends with
``
4. Open the channel in Buzz Desktop: broken-image placeholder; clicking it opens
an empty image viewer.

**Expected behavior**

Embed only what a client can display inline, and link the rest:

- `image/*` → ``
- `video/*` → ``
- anything else → `[](url)`, which renders as a file card

Using the original filename also restores the one piece of information the
sha-named URL destroys — `[report.xlsx](…/9f3c….bin)` tells the reader what they
are opening.

**Impact**

This is the common case for non-interactive agents, which produce documents far
more often than images. The failure is also misleading: it looks like a broken
or inaccessible file, so the reflex is to check permissions or re-upload, when
the bytes were never the problem.

Adjacent, already filed: #2963 / #3083 (the CLI's upload allowlist rejects the
same documents earlier in the pipeline), #5149 and #3241 (`/media/` URLs return
401 outside Desktop, so pasting a raw link is not an alternative), #6791
(rendering Markdown/HTML inline).

**Environment**

- `buzz` CLI built from `main`
- relay 0.2.1, self-hosted
- Buzz Desktop 0.5.19, macOS arm64

Start in crates/buzz-cli/src/commands/messages.rs:658-665 at the `messages send --file` media-content branch, then check how the upload descriptor preserves the original filename. Done means image/* and video/* remain inline embeds, while other attachments use a link containing the original filename and the existing imeta tag remains correct.

Written by the indexing model from the issue text.