fix(downloader): offload download_repo to a dedicated thread when a Tokio runtime is active

[inureyes]

Summary

mlxcel serve -m <repo-id> aborted with Tokio's "Cannot start a runtime from within a runtime" whenever the model had to be auto-downloaded, because download_repo builds its own runtime and calls block_on, which is forbidden on a thread already driving a runtime (run_serve is async). The synchronous mlxcel run path never hit it.

Fix

The download_repo entry point now detects an active runtime via tokio::runtime::Handle::try_current() and runs the unchanged blocking body (download_repo_blocking) on a dedicated OS thread (joined, panics propagated); synchronous callers keep the direct call. This is the issue's "runtime-aware download entry" option: one change makes every current and future caller safe — mlxcel serve, mlxcel-server's #[tokio::main] download path near startup, and the CLI download / run verbs — with identical progress output (the bars write to the same stderr).

Validation

End to end with the release binary and an empty store:

mlxcel serve -m mlx-community/SmolLM2-135M-Instruct-8bit --port 18463
  [mlxcel download] 8 files queued (filtered from 10 total siblings)
  [mlxcel download] complete: downloaded=8 cached=0 total_size=141.02 MiB dest=~/.cache/mlxcel/models/...
  ... Warmup complete

The server starts and answers a /v1/chat/completions request; the same invocation previously aborted at the first internal block_on (the issue's exact repro shape). A missing-repo variant surfaces a clean HTTP 404 error through the serve path instead of the abort. A regression test pins that download_repo called from inside a multi-thread runtime returns a normal error (closed local endpoint, no network access). 123 downloader unit tests, cargo fmt, and cargo clippy --all-targets -- -D warnings are clean.

Closes #463