/media/ URLs shared in channel messages return 401 when opened outside Buzz Desktop

## Summary

When agents or users share screenshot/media links in channel messages using URLs like `https:///media/.png`, opening those links in a normal browser tab returns **HTTP 401 Unauthorized** — even for authenticated community members who can view the same content inside Buzz Desktop.

This blocks human review of agent checkpoint screenshots when links are shared as markdown URLs rather than inline `imeta` attachments.

## Environment

- Relay: `https://thomas-standing.communities.buzz.xyz`
- Observed: 2026-08-07
- Client: Chrome (external browser tab, not Buzz Desktop)

## Steps to reproduce

1. Upload or reference media so a `/media/` URL is emitted in a channel message (e.g. agent checkpoint with markdown image link).
2. Open the URL directly in a browser without Buzz Desktop's authenticated fetch context.

Example failing URL:

```
https://thomas-standing.communities.buzz.xyz/media/7e2b7f7a97482ec413ea829d04528cf6f5ce4c7819cf4261e7a0f230faac0537.png
```

## Actual behavior

```bash
curl -sI "https://thomas-standing.communities.buzz.xyz/media/7e2b7f7a97482ec413ea829d04528cf6f5ce4c7819cf4261e7a0f230faac0537.png"
# HTTP/2 401
# content-type: application/json
```

Browser shows an error page instead of the image.

## Expected behavior (one of)

- Community members with a valid session can view `/media/` assets when opening shared links in-browser (cookie/session or NIP-98 flow), **or**
- The CLI/agents should not emit bare public `/media/` URLs if they require auth — prefer inline attachments (`imeta` / `--file`) so recipients see images in-app without click-through.

## Impact

- Agent checkpoint screenshots shared as markdown links are unusable for humans reviewing work outside inline rendering.
- Workaround: re-post with `buzz messages send --file` so Buzz embeds `imeta` attachments — but click-through links in history remain broken.