Implementace prevodu HTML na PDF

Sluzba prijme adresu HTML dokumentu nebo HTML v tele requestu a vrati PDF.
Navrzena pro dokumenty o stovkach az tisicich stranek.

Rendering:
- WeasyPrint jako vychozi engine, spravne CSS Paged Media, nizka pametova
  narocnost, bez JavaScriptu
- Chromium pres Playwright pro dokumenty dokreslovane skripty
- rezim auto s detekci skriptu a fallbackem pri selhani WeasyPrintu

Velke dokumenty:
- deleni na casti na strukturalnich hranicich, rez nikdy uvnitr tabulky
  nebo odstavce
- dvoupruchodovy render obsahu se skutecnymi cisly stranek, pozice nadpisu
  se ctou z kotev hlasenych u kazde stranky
- cislovani stranek bud pres CSS countery, nebo pres cislovaci vrstvu
  nastampovanou na hotove PDF, rozmer stranky se cte z vysledneho souboru
- Chromium se restartuje po N jobech, nikdy vsak behem beziciho renderu

API:
- POST /convert synchronne, POST /jobs asynchronne se sledovanim stavu,
  stahovanim vysledku, rusenim a volitelnym callbackem
- GET /health s overenim dostupnosti obou enginu a stavem fronty
- OpenAPI respektuje prefix reverse proxy pres root_path

Bezpecnost a provoz:
- SSRF kontrola po DNS resolvu, na kazdem presmerovani a u vsech pozadavku
  prohlizece
- nedostupne assety render nezastavi, ale hlasi se v odpovedi i v logu
- fronta s omezenym poctem workeru, rozpracovane joby se pri ukonceni
  oznaci jako failed, nezmizi potichu
- strukturovane JSON logovani s job_id
- vsechny limity vypnute ve vychozim stavu

Dockerfile je dvoufazovy, obsahuje zavislosti WeasyPrintu, Chromium
a fonty s ceskou diakritikou.

Autentizace zamerne neni implementovana, zpusob predavani neni domluveny.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

documentation/zmeny.md

@@ -0,0 +1,34 @@
+# Zaznam zmen
+
+## 1.0.0
+
+Prvni implementace sluzby.
+
+Pridano:
+
+- synchronni endpoint `POST /convert` s limitem a odkazem na asynchronni cestu
+- asynchronni endpointy `POST /jobs`, `GET /jobs/{id}`,
+  `GET /jobs/{id}/result`, `DELETE /jobs/{id}`
+- `GET /health` s overenim dostupnosti obou enginu a stavem fronty
+- engine WeasyPrint jako vychozi, engine Chromium pres Playwright, rezim `auto`
+  s detekci skriptu a naslednym fallbackem
+- deleni dokumentu na casti na strukturalnich hranicich a slucovani vysledku
+- dvoupruchodovy render obsahu se skutecnymi cisly stranek
+- cislovani stranek pres CSS countery nebo pres cislovaci vrstvu
+- zalozky PDF z nadpisu, vypinatelne pres `outline`
+- profily PDF/A a PDF/UA pres `pdf_profile`
+- SSRF ochrana s kontrolou po DNS resolvu, na kazdem presmerovani a u vsech
+  pozadavku prohlizece
+- hlaseni nedostupnych assetu v odpovedi jobu a v logu
+- fronta s omezenym poctem workeru, zruseni jobu, expirace vysledku
+- volitelny callback po dokonceni jobu
+- strukturovane JSON logovani s `job_id`
+- Dockerfile s WeasyPrintem, Chromiem, fonty s ceskou diakritikou a healthcheckem
+- testy vcetne fixture o zhruba 1200 strankach
+
+Zamerne neimplementovano:
+
+- autentizace, zpusob neni domluveny
+- databaze, Redis ani message broker
+- webove UI
+- jakekoliv limity zapnute ve vychozim stavu