Mobile hardcodes 100 MB media caps, and the relay does not advertise its real limits

Self-hoster report. On a relay configured for larger media, the mobile client still refuses uploads at 100 MB, and there is no way for it to know better.

## What happens

Relay env (self-hosted, deployed as code):

```
BUZZ_MAX_VIDEO_BYTES=4294967296 # 4 GiB
BUZZ_MAX_IMAGE_BYTES=536870912 # 512 MiB
BUZZ_MAX_GIF_BYTES=536870912
BUZZ_MAX_FILE_BYTES=536870912
```

A 200 MB upload through Blossom `PUT /upload` succeeds against that relay and reads back byte-identical, so the server side genuinely accepts it. But the mobile app refuses before it ever reaches the network:

> Video is too large (…MB). Maximum is 100MB.

Source: `mobile/lib/shared/relay/media_upload.dart`

```dart
const _maxVideoSizeBytes = 100 * 1024 * 1024; // 100MB
const _maxFileSizeBytes = 100 * 1024 * 1024; // 100MB
```

These are compile-time constants, so a self-hoster cannot raise them without forking and rebuilding the app — and the number does not correspond to anything the relay says.

## Why it cannot be fixed client-side today

The relay's NIP-11 document advertises `limitation` for messages and subscriptions, but nothing about media:

```json
{"max_message_length":524288,"max_subscriptions":1024,"max_filters":10,"max_limit":1000,…}
```

So even a client that wanted to adapt has nothing to read.

## Suggested fix (two halves, either is useful alone)

1. **Relay**: advertise the media caps — e.g. `limitation.max_upload_bytes`, or a media-specific block carrying the image/gif/video/file values the relay already holds in `BUZZ_MAX_*`.
2. **Mobile**: treat the hardcoded constants as a fallback and prefer the advertised values, the way the size check would work if the server were the source of truth. Same for the MIME allowlist, which is also compile-time (`_allowedVideoMimeTypes = {'video/mp4'}`) and rejects formats a relay may happily store.

The desktop client does not appear to impose an equivalent media cap, so today the same account can upload a 200 MB video from desktop and be refused on mobile — which reads as a bug to the user rather than a policy.

Happy to send a PR for either half if you tell me which shape you would accept for the advertisement (a flat `max_upload_bytes`, or per-kind values).