Allow text/html file uploads on the relay generic file path (served as download)

## Problem

Uploading an `.html` file is rejected by the relay with `DisallowedContentType("text/html")`.

`text/html` is on the relay's deny list for the generic file-upload path:

```rust
// crates/buzz-media/src/validation.rs
const BLOCKED_FILE_MIME_TYPES: &[&str] = &[
// Active web content — stored-XSS vectors.
"text/html",
"application/xhtml+xml",
"image/svg+xml",
...
];
```

## Why this matters

HTML files are a common, legitimate attachment in day-to-day work — especially in agent-heavy communities:

- Agents frequently produce self-contained HTML reports, dashboards, diagrams, and visualizations as their work output, and currently have no way to share them in a channel.
- Exported docs (notebooks, coverage reports, saved pages) are HTML too.

Right now the only workarounds are zipping the file or hosting it elsewhere, both of which add friction for what is just a document hand-off.

## Why it seems safe to allow

The doc comment on `BLOCKED_FILE_MIME_TYPES` itself notes that generic files are already served with:

- `Content-Disposition: attachment`
- `X-Content-Type-Options: nosniff`
- `CSP: default-src 'none'`

…which "already neutralises them — this allowlist-of-denials is defence in depth". So the download path never renders the HTML in the app's origin; the deny list is only guarding against a future header regression.

## Suggested fix

Remove `text/html` (and optionally `application/xhtml+xml`) from `BLOCKED_FILE_MIME_TYPES` so HTML files take the normal generic-file path and are served strictly as downloads.

If dropping the defence-in-depth layer entirely feels too risky, alternatives:

1. Serve blocked-but-textual types with a rewritten `Content-Type: text/plain` (still `attachment` + `nosniff`), so even a header regression can't execute them.
2. Keep the deny list but add a regression test asserting the attachment/nosniff/CSP headers on the file-serving path, making the header contract explicit instead of blocking the format.

Executables and SVG (which can be referenced inline via ``) can stay blocked — this request is only about HTML documents as downloadable attachments.

## Related

- #3083 tracks aligning the `buzz-cli` allowlist with the relay's generic file path; if this lands, the CLI list would need `text/html` as well so agents can actually upload these files.

Start in crates/buzz-media/src/validation.rs at BLOCKED_FILE_MIME_TYPES, then inspect the relay's generic file-serving path and its existing response headers. Confirm the chosen handling for text/html, and verify that HTML uploads are accepted while remaining downloads with Content-Disposition: attachment, nosniff, and the stated CSP; add or run the relevant regression test if available.

Written by the indexing model from the issue text.