Crash on unknown video `Site` variant (Vimeo) — every related_videos response with a non-YouTube host fails to deserialize

### Description

## Summary

Any Discord `/request` for a movie or TV show fails outright with a generic
error whenever Seerr's `/movie/{movieId}` or `/tv/{tvId}` response includes
a `relatedVideos` entry whose `site` is anything other than `"YouTube"`
(e.g. `"Vimeo"`). The entire response fails to deserialize, so the whole
request dies — not just the video/trailer portion of the metadata.

## Steps to reproduce

1. Configure a Seerr backend and issue `/request movie` (or `/request series`)
for a title whose TMDB entry has at least one video in
`videos.results[]` hosted on Vimeo rather than YouTube.
2. Select the title from the search results.
3. Observe: the interaction fails with doplarr_rs's generic error response
to the user, and the following appears in the container logs:

ERROR doplarr::providers::seerr: Fetching movie details - Serialization error: unknown variant Vimeo, expected YouTube at line 1 column 2239
ERROR doplarr: Failed to run coroutine to completion uuid=... error=error in serde: unknown variant Vimeo, expected YouTube at line 1 column 2239

Caused by:
unknown variant Vimeo, expected YouTube at line 1 column 2239

Confirmed reproducible across multiple different Discord users and multiple
attempts against the same title, on doplarr_rs v4.6.0.

## Root cause

- `seerr_api/src/models/related_video.rs` (vendored, auto-generated Seerr API
client) defines:

#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)]
pub enum Site {
#[serde(rename = "YouTube")]
YouTube,
}

with no catch-all variant, so serde hard-fails on any other string value.

- This mirrors an under-specified field in Seerr's own OpenAPI spec
(seerr-api.yml), which declares `site: { type: string, enum: ['YouTube'] }`
— confirmed present in both Seerr's current release and its develop
branch. Seerr itself just proxies TMDB's videos.results[].site field,
which legitimately includes other hosts (Vimeo confirmed) that the spec
never declared.
- Notably, RelatedVideo/Site is deserialized as part of
MovieDetails.related_videos / the TV equivalent but is never read
anywhere in doplarr's own bot logic (doplarr/src/) — it's a fully dead
field as far as request-handling is concerned. It still has to parse
successfully for the whole MovieDetails/TvDetails struct to succeed,
which is what turns an irrelevant metadata field into a hard outage for
the entire request.

## Possible fixes (either would resolve this; noting both rather than
picking one, since the maintainers may prefer one style over the other)

(a) Make the Site enum tolerant of unknown values, e.g.:

#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)]
pub enum Site {
#[serde(rename = "YouTube")]
YouTube,
#[serde(other)]
Unknown,
}

This is regenerated/vendored code, so this would need to be applied either
as a post-generation patch or upstream in whatever process produces
seerr_api/.

(b) Use the existing graceful-degradation helper for these two calls.
doplarr/src/providers/seerr.rs already has a tolerate_response_parse_error()
helper, used elsewhere in the same file to treat a SeerrApiError::Serde
failure as "succeeded, but couldn't parse — return None" rather than
propagating a hard error. The two call sites that crash here —
movie_movie_id_get and tv_tv_id_get — currently use the stricter require()
wrapper instead. Switching just these two calls to the existing tolerant
helper would make the whole class of "Seerr/TMDB response contains a field
we don't fully model" errors degrade gracefully instead of taking down the
request.

## Related

This traces back to an accuracy gap in Seerr's own OpenAPI spec (site enum
only lists 'YouTube', doesn't reflect what TMDB actually returns) — filing
a companion issue on seerr-team/seerr as well, since any other client
generating a typed model from that spec would hit the same class of bug.

## Environment

- doplarr_rs: v4.6.0 (ghcr.io/activexray/doplarr_rs:latest at time of report)
- Seerr: v3.4.1 (ghcr.io/seerr-team/seerr)
- Backend: Seerr (not tested against direct Radarr/Sonarr backends, which
don't proxy this field)

### Version

v4.6.0.

### Steps to Reproduce

1. Configure a Seerr backend and issue `/request movie` (or `/request series`) for a title whose TMDB entry has at least one video in `videos.results[]` hosted on Vimeo rather than YouTube.
2. Select the title from the search results.
3. Observe: the interaction fails with doplarr_rs's generic error response to the user, and the following appears in the container logs:

ERROR doplarr::providers::seerr: Fetching movie details - Serialization error: unknown variant Vimeo, expected YouTube at line 1 column 2239
ERROR doplarr: Failed to run coroutine to completion uuid=... error=error in serde: unknown variant Vimeo, expected YouTube at line 1 column 2239

Caused by:
unknown variant Vimeo, expected YouTube at line 1 column 2239

Confirmed reproducible across multiple different Discord users and multiple attempts against the same title, on doplarr_rs v4.6.0.

### Backend

Seerr

### Deployment Method

Docker

### Logs

```shell
ERROR doplarr::providers::seerr: Fetching movie details - Serialization error: unknown variant Vimeo, expected YouTube at line 1 column 2239
ERROR doplarr: Failed to run coroutine to completion uuid=... error=error in serde: unknown variant Vimeo, expected YouTube at line 1 column 2239

Caused by:
unknown variant Vimeo, expected YouTube at line 1 column 2239
```

### Screenshots

_No response_

### Host Operating System

Ubuntu Server 24.04 LTS

### Additional Context

## Root cause

- `seerr_api/src/models/related_video.rs` (vendored, auto-generated Seerr API client) defines:

#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)]
pub enum Site {
#[serde(rename = "YouTube")]
YouTube,
}

with no catch-all variant, so serde hard-fails on any other string value.

- This mirrors an under-specified field in Seerr's own OpenAPI spec (seerr-api.yml), which declares `site: { type: string, enum: ['YouTube'] }` — confirmed present in both Seerr's current release and its develop branch. Seerr itself just proxies TMDB's videos.results[].site field, which legitimately includes other hosts (Vimeo confirmed) that the spec never declared.
- Notably, RelatedVideo/Site is deserialized as part of MovieDetails.related_videos / the TV equivalent but is never read anywhere in doplarr's own bot logic (doplarr/src/) — it's a fully dead field as far as request-handling is concerned. It still has to parse successfully for the whole MovieDetails/TvDetails struct to succeed, which is what turns an irrelevant metadata field into a hard outage for the entire request.

## Possible fixes (either would resolve this; noting both rather than picking one, since the maintainers may prefer one style over the other)

(a) Make the Site enum tolerant of unknown values, e.g.:

#[derive(Clone, Copy, Debug, Eq, PartialEq, Ord, PartialOrd, Hash, Serialize, Deserialize)]
pub enum Site {
#[serde(rename = "YouTube")]
YouTube,
#[serde(other)]
Unknown,
}

This is regenerated/vendored code, so this would need to be applied either as a post-generation patch or upstream in whatever process produces seerr_api/.

(b) Use the existing graceful-degradation helper for these two calls. doplarr/src/providers/seerr.rs already has a tolerate_response_parse_error() helper, used elsewhere in the same file to treat a SeerrApiError::Serde failure as "succeeded, but couldn't parse — return None" rather than propagating a hard error. The two call sites that crash here — movie_movie_id_get and tv_tv_id_get — currently use the stricter require() wrapper instead. Switching just these two calls to the existing tolerant helper would make the whole class of "Seerr/TMDB response contains a field we don't fully model" errors degrade gracefully instead of taking down the request.

## Related

This traces back to an accuracy gap in Seerr's own OpenAPI spec (site enum only lists 'YouTube', doesn't reflect what TMDB actually returns) — filing a companion issue on seerr-team/seerr as well, since any other client generating a typed model from that spec would hit the same class of bug.

### Search Existing Issues

- [x] Yes, I have searched existing issues.

### Code of Conduct

- [x] I agree to follow Doplarr's Code of Conduct.