feat(downloads): a Facebook cookie download stuck at "Cannot parse data" is retried as Chrome

Measured on dev: with the user's cookie some reels still answer "Cannot parse
data" and only extract when the request impersonates Chrome. Impersonation is
a second attempt behind that one error, only when a cookie is attached — links
that already download with the cookie keep their plain path, and without a
cookie the same error is the login wall.

curl_cffi is pinned inside yt-dlp's supported range (0.10-0.15; outside it
every target silently reports "unavailable"); the lock only gains the new
packages. A test fails the gate if the locked pair can no longer impersonate.

backend/requirements.lock

@@ -7,6 +7,7 @@ Authlib==1.7.2
 Mako==1.4.1
 MarkupSafe==3.0.3
 PyYAML==6.0.3
+Pygments==2.21.0
 SQLAlchemy==2.0.52
 alembic==1.19.1
 annotated-doc==0.0.5
@@ -21,6 +22,7 @@ cffi==2.1.1
 charset-normalizer==3.5.1
 click==8.4.2
 cryptography==50.0.0
+curl_cffi==0.15.0
 fastapi==0.141.1
 feedparser-sgmllib==2.1.0
 feedparser==6.0.14
@@ -32,6 +34,8 @@ httpx==0.28.1
 idna==3.18
 itsdangerous==2.2.0
 joserfc==1.7.4
+markdown-it-py==4.2.0
+mdurl==0.1.2
 mutagen==1.48.1
 numpy==2.5.2
 psycopg-binary==3.3.4
@@ -45,6 +49,7 @@ pydantic_core==2.46.4
 python-dotenv==1.2.3
 python-multipart==0.0.32
 requests==2.34.2
+rich==15.0.0
 starlette==1.6.0
 typing-inspection==0.4.4
 typing_extensions==4.16.0