fix: handle hf_hub_download crash when stderr lacks a real file descriptor

[tobocop2]

Problem

hf_hub_download crashes with ValueError: bad value(s) in fds_to_keep in any environment where sys.stderr is not backed by a real file descriptor.

The download itself is fine. Only tqdm's progress bar initialization fails, but because _create_progress_bar has no safety net, it takes down the entire download.

Affected environments

Any runtime where sys.stderr is not backed by a real file descriptor:

• Textual TUI apps
• Jupyter notebooks
• pytest capture
• WSGI/ASGI web servers (gunicorn, uvicorn)
• Sandboxed/containerized runtimes
• IDE embedded terminals

Root cause

_create_progress_bar calls cls(disable=disable, name=name, **kwargs) with no exception handling. When stderr's fileno() returns -1, tqdm's __init__ tries to create a multiprocessing lock, which spawns a resource tracker subprocess via fork_exec(), which rejects the invalid fd.

Crash Demo

Fix

Add a _SafeTqdm subclass that uses a threading.RLock instead of a multiprocessing lock, and wrap both cls() calls in _create_progress_bar with try/except (OSError, ValueError) to fall back to _SafeTqdm.

Fixes #4066

---

Note

Low Risk
Low risk: changes are limited to progress bar initialization/error handling and should not affect download correctness, only whether/which progress reporting is shown.

Overview
Prevents hf_hub_download/snapshot progress reporting from crashing in environments where sys.stderr.fileno() is invalid by wrapping _create_progress_bar construction in try/except (OSError, ValueError) and falling back to a new _SafeTqdm that uses a threading.RLock.

When the HF tqdm subclass cannot be initialized, the code now emits a warning and continues the download without progress reporting. Adds a regression test that patches sys.stderr to return -1 for fileno() and asserts the download succeeds.

^{Reviewed by Cursor Bugbot for commit 43399d3. Bugbot is set up for automated code reviews on this repo. Configure here.}