Optimize image size and XMLTV runtime resources

[cerede2000]

What changed

• make XMLTV imports memory-flat by streaming records through a disk-backed batch spool under /data
• limit concurrent XMLTV workers to one by default and add content-hash smart-sync fallback
• keep 7-Zip, uvloop, and httptools while removing bytecode and unused Uvicorn extras from the image
• avoid loading detail-only programme fields in collection endpoints and remove the unused title B-tree index
• cancel stale frontend searches and bound authentication attempt tracking
• add an amd64 image-size budget of 185 MiB to CI

Why

Large or concurrent XMLTV imports retained two full Python representations while downloads and decompressed documents lived in a RAM-backed /tmp. This caused avoidable RAM and CPU spikes. The runtime image also embedded bytecode and unused server dependencies.

Measured impact

A 100,000-programme / 16 MiB synthetic feed dropped from 96.4 MiB peak traced Python allocations to 2.1 MiB. The disk spool was 12.7 MiB. A fresh production virtualenv dropped from 43 MiB to 41 MiB even before accounting for the 20.9 MiB of bytecode present in the published Linux layer.

Validation

• backend: Ruff + format check + 129 tests
• frontend: ESLint + 90 tests + production build
• Alembic upgrade tested from revision 849e860670eb with existing data preserved
• workflow and Compose YAML parsed successfully