build(deps): bump postcss-selector-parser from 7.1.1 to 7.1.5 - #798

… — zamyka 4 CVE i odblokowuje pip-audit (#809)

* ci(deps): zbiorczy bump akcji GitHub (PR-y #806, #805, #788)

Trzy PR-y dependabota z ekosystemu github-actions, scalone recznie zamiast
mergowania po kolei. Wszystkie to podmiana SHA przy zachowanym pinowaniu
do commita + komentarz z tagiem (polityka repo: akcje pinowane po SHA,
nie po ruchomym tagu).

* anthropics/claude-code-action 1.0.193 -> 1.0.216  (#806)
  .github/workflows/claude.yml
* actions/deploy-pages 5.0.0 -> 5.0.1               (#805)
  .github/workflows/docs.yml
* docker/setup-buildx-action 4.2.0 -> 4.3.0         (#788)
  build-docker-images.yml (2x), promote.yml,
  release-candidate.yml, tests.yml

Weryfikacja: po podmianie w drzewie nie zostal ani jeden ze starych SHA
(grep po .github/ pusty).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011aZqYiv56cwAudG2CPS3k5

* build(deps): postcss-selector-parser 7.1.1 -> 7.1.5 (PR #798)

Zaleznosc przechodnia (przez postcss-modules-*), wiec `yarn upgrade
postcss-selector-parser` jej nie rusza — podniesiony wpis w yarn.lock
wprost, wersja/resolved/integrity wziete z PR-a dependabota.

Weryfikacja: `yarn install --frozen-lockfile` przechodzi (lock rozwiazuje
sie bez zmian, integrity zgadza sie z tarballem z rejestru), a
node_modules/postcss-selector-parser/package.json raportuje 7.1.5.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011aZqYiv56cwAudG2CPS3k5

* deps: grupa python-minor-and-patch + pypdf/webob/uvicorn + sync pinu ruffa

Cztery PR-y dependabota z ekosystemu uv, scalone recznie w jedna zmiane.
Powod: kazdy z nich rusza uv.lock, wiec mergowanie po kolei wymusza
rebase i osobny przebieg CI dla kazdego kolejnego.

Grupa python-minor-and-patch (#807), 12 pakietow:

  simplejson              4.1.1  -> 4.1.2
  django-flexible-reports 0.4.2  -> 0.5.0
  django-tables2          3.0.0  -> 3.0.1
  nh3                     0.3.6  -> 0.3.7
  cryptography           50.0.0  -> 50.0.1   (tylko lock)
  crispy-bootstrap5      2026.3  -> 2026.9
  xhtml2pdf              0.2.17  -> 0.2.18
  gunicorn               26.0.0  -> 26.2.0
  django-oauth-toolkit    3.4.0  -> 3.4.1
  pytest-rerunfailures     16.5  -> 16.6.1
  ruff                   0.16.3  -> 0.16.6
  djlint                 1.44.2  -> 1.45.0   (tylko lock)

Pozostale trzy PR-y:

  uvicorn[standard]      0.52.3  -> 0.52.4   (#790)
  pypdf                  6.15.0  -> 6.16.1   (#799)
  webob                  1.8.10  -> 1.8.11   (#794)

BEZPIECZENSTWO — pypdf i webob zamykaja 4 fixable CVE, ktore od kilku
dni wywalaja gate `pip-audit` (job "pip-audit scan"), blokujac takze
niezwiazane PR-y (m.in. #804):

  pypdf 6.15.0  CVE-2026-84309 / -84310 / -84311   fix: 6.16.1
  webob 1.8.10  CVE-2026-54770                     fix: 1.8.11

Weryfikacja lokalna, dokladnie ta komenda co w CI (uv export --no-dev |
pip-audit --disable-pip --no-deps): przed zmiana "Found 4 known
vulnerabilities in 2 packages", po zmianie "No known vulnerabilities
found".

RUFF — bump 0.16.3 -> 0.16.6 wymaga rownoleglej zmiany rev w
.pre-commit-config.yaml. To sa dwa fizycznie rozne binaria (pre-commit
buduje wlasne srodowisko z wheela spod `rev:`), a dependabot tego
sprzezenia nie widzi, bo sledzi tylko ekosystem uv. Pilnuje tego bramka
bin/check-ruff-pin-sync.py — sam PR #807 by ja wywalil. Po synchronizacji
skrypt zwraca 0.

Ruff 0.16.6 nie wnosi nowych naruszen: na tym drzewie 0.16.3 i 0.16.6
daja identyczny wynik — 122 errors z tym samym rozkladem regul oraz
124 pliki do reformatu. Caly ten dlug jest pre-existing na dev i zgodnie
z konwencja repo (lint changed-files-only) zostaje nietkniety.

COOLDOWN — `uv lock --upgrade-package` celuje w najnowsze wydanie, co po
cichu omija 3-dniowy cooldown z .github/dependabot.yml (ochrona przed
atakami typu LiteLLM). Dwa pakiety przestrzelilo i zostaly przypiete do
wersji, ktore odlezaly swoje:

  djlint  1.46.1 wydany dzis (2026-09-08) -> przypiety 1.45.0 (2026-09-03)
  pypdf   6.18.0 wydany wczoraj           -> przypiety 6.16.1 (2026-08-14)

WERSJA uv UZYTA DO PRZELICZENIA LOCKA — celowo `uv@0.11.29`, czyli pin
z CI (setup-uv w jobach `lockfile` / `lint` / `pip-audit`), a NIE lokalne
uv 0.11.14 ani 0.11.15 z hooka uv-pre-commit. Powod: przy przeliczaniu
locka starsze uv rozpisuje marker `platform_python_implementation !=
'PyPy'` na cala rozwiazana grafe zaleznosci — 13 wystapien rosnie do ~700,
a diff uv.lock puchnie z ~500 do ~1900 linii czystego szumu. Wersje
pakietow wychodza identyczne (sprawdzone: 367 pakietow, zero roznic
w parach nazwa/wersja), wiec to wylacznie metadane, ale zasmiecaja
review pliku, ktory trzeba czytac uwaznie. Zweryfikowane empirycznie:
to samo `--upgrade-package simplejson` na czystym dev daje 700 markerow
pod 0.11.14 i 0.11.15, a 13 pod 0.11.29.

    UWAGA: komentarz przy hooku uv-pre-commit w .pre-commit-config.yaml
    ("Trzymaj z grubsza w parze z wersja uv w uzyciu (obecnie 0.11.14)")
    jest wiec juz nieaktualny i doradza dokladnie to, co produkuje churn.
    Lock na dev pochodzi z nowszego uv. Aktualizacja tego komentarza
    i pinu hooka to osobna zmiana, poza zakresem tego PR-a.

Reszta lockfile bez zmian — uzyty celowany `--upgrade-package` dla 15
pakietow, nie zbiorczy `uv lock --upgrade`. Diff uv.lock to 15 zmian
wersji + ich sdist/wheels, 11 linii `requires-dist` (lustro zmian
w pyproject.toml) i jedna usunieta zaleznosc `packaging`, ktora gunicorn
26.2.0 porzucil u siebie.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011aZqYiv56cwAudG2CPS3k5

* docs(deps): udokumentuj `[tool.uv] environments` + zrownaj dolna granice z requires-python

Linia `environments` w [tool.uv] jest load-bearing, a stala bez slowa
wyjasnienia. Wjechala commitem 0f3f049 o wiadomosci "Prepare fix,
maybe" (2025-10-14) — razem z `urllib3>=2.2.3` i `vcrpy>=6.0.2`, i to
byl wlasnie ten fix, tylko nigdzie nieopisany. Odtworzenie powodu
zajelo osobne sledztwo, wiec zapisuje je przy samej linii.

POWOD HISTORYCZNY. uv robi universal resolution: jeden lock ma byc
poprawny dla kazdej platformy i kazdego interpretera, takze takiego,
ktorego nigdy nie uruchomimy. vcrpy 6.0.2 deklarowalo:

    urllib3;   platform_python_implementation != "PyPy" and python_version >= "3.10"
    urllib3<2; platform_python_implementation == "PyPy"

czyli galaz PyPy zadala urllib3<2, nie do pogodzenia z urllib3>=2.2.3.
Wykluczenie PyPy kasuje te galaz i odblokowuje rezolucje.

STAN OBECNY — zweryfikowany, nie zgadniety. Przeskanowany caly graf
z uv.lock (364 pakiety z rejestru, 3 pominiete jako editable/git, zero
bledow pobrania metadanych). Warunki `== "PyPy"` wystepuja w czterech
miejscach:

    celery 5.6.3           brotlipy>=0.7.0  extra == "brotli"
    fonttools 4.62.1       munkres          extra == "all"
    fonttools 4.62.1       munkres          extra == "interpolatable"
    jaraco-functools 4.4.0 mypy<1.19        extra == "type"

Wszystkie cztery siedza za extrasami, ktorych nie wlaczamy — brotlipy,
munkres ani mypy nie wystepuja w uv.lock, a z fonttools bierzemy
wylacznie extra `woff`. vcrpy 8.3.0 nie ma juz swojego warunku.

Zdjecie wykluczenia daje dzis DOKLADNIE te same wersje: 367 pakietow,
zero roznic w parach nazwa/wersja. Zostaje mimo to — kosztuje 13 linii
resolution-markers w naglowku locka i chroni przed powtorka klasy
problemu, ktora juz raz zablokowala rezolucje. Bez niego cryptography,
pynacl i uvicorn[standard] odzyskuja markery PyPy na krawedziach do
cffi/uvloop, wiec lock i tak nie robi sie prostszy.

DOLNA GRANICA. `python_version >= '3.10'` -> `>= '3.11'`. Byla martwa
(przeciecie z requires-python = ">=3.11,<3.15" i tak dawalo 3.11), ale
mylnie sugerowala wsparcie dla 3.10. uv.lock po tej zmianie jest
BIT W BIT identyczny (`uv lock` nie ruszyl pliku, `uv lock --check`
przechodzi) — to zmiana czysto opisowa.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011aZqYiv56cwAudG2CPS3k5

---------

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