Crash with long traceback when flixhq.to is down

[Raveed-Ullah-Usmani]

Metadata (please complete the following information)
Version: 1.8.1.17
OS: Arch Linux (kernel 7.1.4-arch1-1, Python 3.14.6)
Movie: avatar

Describe the bug
Any upstream HTTP error crashes with a full double traceback instead of a
readable message.

While flixhq.to is returning 522 (Cloudflare can't reach the origin), every
search dies with two chained tracebacks spanning ~40 lines of terminal.
The user-facing outcome is RuntimeError: Search failed: Server error '522 <none>', buried under internal frames from httpx/_models.py and

✢
The user-facing outcome is RuntimeError: Search failed: Server error '522 <none>', buried under internal frames from httpx/_models.py and
flix_cli/core/__flix_cli__.py.

The 522 is an upstream outage and not flix-cli's fault, but the crash is:
a transient/unreachable host is a completely expected condition for a
scraper, and it should produce a one-line "flixhq.to is unreachable
(HTTP 522), try again later" rather than a stack dump that reads like a
bug in the tool.

Two things make it worse than a plain unhandled exception:

1. search_content catches the HTTPStatusError at
   core/__flix_cli__.py:147-149 and re-raises it as a bare RuntimeError.
   That converts one traceback into two chained ones ("During handling of
   the above exception, another exception occurred") and loses the typed
   exception, so nothing upstream can distinguish "site down" from
   "parse failed" from "no results".
2. Nothing distinguishes a 5xx (retry later) from a 404 (bad URL) or a 403
   (blocked/needs different headers), so the user has no idea whether to
   wait, update, or report.

Steps To Reproduce

1. Run flix-cli avatar at a time when flixhq.to returns 5xx
2. Observe the double traceback

Deterministic repro without waiting for a real outage — point the constant
at any host that reliably 5xxes:

1. Set FLIXHQ_BASE_URL = "https://httpbin.org/status/522" in
   core/__flix_cli__.py:24
2. Run flix-cli avatar

Current upstream state at time of filing: curl -o /dev/null -w '%{http_code}' https://flixhq.to/ returns 522 for both / and /search/avatar, so the
origin is down site-wide rather than the search endpoint being broken.

Expected behavior
A single-line error, no traceback, and a non-zero exit code. Something like:

Error: flixhq.to is unreachable (HTTP 522). The site may be down — try again later.

Suggested shape: catch httpx.HTTPStatusError / httpx.RequestError
separately from parse errors, print via the existing rich console, and
raise typer.Exit(1). Keep the traceback behind an existing verbose/debug
flag if one is wanted for real bugs.

Screenshots (if applicable)

Additional context
Reproduced on both the AUR/system install under
/usr/lib/python3.14/site-packages and a fresh uv sync clone of main —
same version, same behavior.
flix_cli/core/__flix_cli__.py.

The 522 is an upstream outage and not flix-cli's fault, but the crash is:
a transient/unreachable host is a completely expected condition for a
scraper, and it should produce a one-line "flixhq.to is unreachable
(HTTP 522), try again later" rather than a stack dump that reads like a
bug in the tool.

Two things make it worse than a plain unhandled exception:

1. search_content catches the HTTPStatusError at
   core/__flix_cli__.py:147-149 and re-raises it as a bare RuntimeError.
   That converts one traceback into two chained ones ("During handling of
   the above exception, another exception occurred") and loses the typed
   exception, so nothing upstream can distinguish "site down" from
   "parse failed" from "no results".
2. Nothing distinguishes a 5xx (retry later) from a 404 (bad URL) or a 403
   (blocked/needs different headers), so the user has no idea whether to
   wait, update, or report.

Steps To Reproduce

1. Run flix-cli avatar at a time when flixhq.to returns 5xx
2. Observe the double traceback

Deterministic repro without waiting for a real outage — point the constant
at any host that reliably 5xxes:

1. Set FLIXHQ_BASE_URL = "https://httpbin.org/status/522" in
   core/__flix_cli__.py:24
2. Run flix-cli avatar

Current upstream state at time of filing: curl -o /dev/null -w '%{http_code}' https://flixhq.to/ returns 522 for both / and