deps: zbiorcza aktualizacja 8 PR-ów dependabota (uv + actions + yarn) — zamyka 4 CVE i odblokowuje pip-audit

[mpasternak]

Zbiorcza aktualizacja zaległych zależności — zastępuje 8 otwartych PR-ów
dependabota: #807, #806, #805, #799, #798, #794, #790, #788.

Dlaczego zbiorczo, a nie merge po kolei

Cztery z tych PR-ów (#807, #799, #794, #790) ruszają ten sam plik
uv.lock. Zmergowanie pierwszego unieważnia pozostałe trzy — dependabot
musi je przerebase'ować, każdy z osobnym pełnym przebiegiem CI. Jedna
zmiana rozwiązuje lock raz.

Do tego #807 sam z siebie nie przeszedłby bramki repo: podbija
ruff==0.16.3 -> 0.16.6 w pyproject.toml, ale dependabot śledzi tylko
ekosystemy uv / github-actions / docker, więc nie widzi drugiego pinu
ruffa w .pre-commit-config.yaml. Pilnuje ich bin/check-ruff-pin-sync.py.
Tutaj oba są podniesione razem.

🔒 Bezpieczeństwo — 4 fixable CVE, odblokowuje gate pip-audit

pypdf i webob zamykają cztery CVE, które od kilku dni wywalają job
pip-audit scan i blokują też niezwiązane PR-y (m.in. #804):

Pakiet	Wersja	CVE	Fix
pypdf	6.15.0	CVE-2026-84309	6.16.0
pypdf	6.15.0	CVE-2026-84310	6.16.1
pypdf	6.15.0	CVE-2026-84311	6.16.1
webob	1.8.10	CVE-2026-54770	1.8.11

Weryfikacja lokalna dokładnie tą komendą, co w CI (uv export --no-dev →
pip-audit --disable-pip --no-deps):

• przed: Found 4 known vulnerabilities in 2 packages
• po: No known vulnerabilities found

Co się zmienia

Python — uv (#807, #799, #794, #790)

Pakiet	Z	Na
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
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
uvicorn[standard]	0.52.3	0.52.4
pypdf	6.15.0	6.16.1
webob	1.8.10	1.8.11

Użyty celowany uv lock --upgrade-package (15 pakietów), nie zbiorczy
uv lock --upgrade — reszta lockfile bez ruchu.

GitHub Actions (#806, #805, #788)

• anthropics/claude-code-action 1.0.193 → 1.0.216
• actions/deploy-pages 5.0.0 → 5.0.1
• docker/setup-buildx-action 4.2.0 → 4.3.0 (5 miejsc w 4 workflowach)

Pinowanie po SHA zachowane, komentarze z tagiem zaktualizowane.

npm / yarn (#798)

• postcss-selector-parser 7.1.1 → 7.1.5 (zależność przechodnia przez
  postcss-modules-*, więc yarn upgrade jej nie rusza)

⚠️ Do świadomej akceptacji: django-oauth-toolkit 3.4.1

Dependabot oznaczył to jako semver-patch, ale release jest „dominated by
security hardening" i zmienia zachowanie:

1. Exact matching redirect_uri wg RFC 9700 §2.1 — żądanie nie może już
   nieść query/path params, credentials ani fragmentu, których nie ma
   w zarejestrowanym URI.
2. redirect_to_uri_allowed() → check_redirect_to_uri_allowed(); kod
   owijający starą nazwę przestaje wpływać na decyzję.
3. REFRESH_TOKEN_EXPIRE_SECONDS egzekwowane przy okazaniu refresh
   tokena, nie tylko przez zamiatanie cleartokens.
4. Wbudowane templaty linkują własny arkusz stylów zamiast CDN — wymaga
   collectstatic.

Sprawdzone w tym repo:

• (1) src/oauth_mcp/views_dcr.py zapisuje redirect_uris
  dokładnie tak, jak zadeklarował klient (allowlista wzorców tylko
  filtruje), a klient odsyła ten sam URI w /authorize → exact match się
  spina. Pokryte testami oauth_mcp/tests/test_authorize.py,
  test_flow_integration.py, test_consent.py.
• (2) brak w src/ jakiegokolwiek wywołania/owinięcia
  redirect_to_uri_allowed ani redirect_uri_allowed → nie dotyczy.
• (3) settings/base.py ma już REFRESH_TOKEN_EXPIRE_SECONDS = 7 dni
  z komentarzem „(NIE None!)" — nowe egzekwowanie realizuje intencję, która
  do tej pory działała tylko przy zamiataniu. Efekt w produkcji: refresh
  tokeny starsze niż 7 dni będą odrzucane od razu przy odświeżeniu.
• (4) collectstatic leci w build stage obrazu (kontrakt static files)
  oraz w make assets → pokryte.

Pozostałe dwa nieoczywiste bumpy sprawdzone w changelogach:
django-flexible-reports 0.5.0 to czysty dodatek (Report.set_order_by,
ColumnOrder nietknięty), crispy-bootstrap5 2026.9 to samo „Confirmed
support for Django 6.1" bez zmian w kodzie.

Cooldown — dwa pakiety cofnięte

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 przestrzeliły i zostały przypięte do wersji, które
odleżały swoje:

Pakiet	uv chciał	Wydany	Przypięte
djlint	1.46.1	dziś (2026-09-08)	1.45.0 (2026-09-03)
pypdf	6.18.0	wczoraj (2026-09-07)	6.16.1 (2026-08-14)

🔎 Znalezione po drodze: pin uv w .pre-commit-config.yaml jest nieaktualny

Lock przeliczony celowo przez uv@0.11.29 — pin z CI (setup-uv
w jobach lockfile / lint / pip-audit), a nie lokalnym uv 0.11.14
ani 0.11.15 z hooka uv-pre-commit.

Powód: przy przeliczaniu locka starsze uv rozpisuje marker
platform_python_implementation != 'PyPy' na całą rozwiązaną grafę —
13 wystąpień rośnie do ~700, a diff uv.lock puchnie z ~500 do ~1900
linii czystego szumu. Wersje pakietów wychodzą identyczne (sprawdzone:
367 pakietów, zero różnic w parach nazwa/wersja; uv pip list po uv sync
też bit w bit ten sam), więc to wyłącznie metadane — ale zaśmiecają review
pliku, który trzeba czytać uważnie.

Zweryfikowane empirycznie — to samo uv lock --upgrade-package simplejson
na czystym dev:

uv	markery != 'PyPy'
0.11.14 (lokalne)	700
0.11.15 (hook uv-pre-commit)	700
0.11.29 (CI)	13 ✅

Komentarz przy hooku uv-pre-commit mówi „Trzymaj z grubsza w parze
z wersją uv w użyciu (obecnie 0.11.14)" — doradza dokładnie to, co
produkuje churn, bo lock na dev pochodzi z nowszego uv.
Aktualizacja tego komentarza i pinu hooka to osobna zmiana, świadomie
poza zakresem tego PR-a.

Zakres problemu jest przy tym węższy, niż brzmi — sprawdzone wprost:

Sytuacja	hook (uv 0.11.15)
lock już zgodny → hook robi uv lock	no-op, markery zostają 13 ✅
zmiana constraintu w pyproject.toml → wymuszone przeliczenie	13 → 699 💥

Czyli hook nie psuje zwykłych commitów; odpala się dopiero w PR-ach, które
realnie ruszają zależności — czyli takich jak ten.

📌 Dorzucone: dokumentacja [tool.uv] environments (commit eda88c665)

Przy okazji analizy locka wyszło, że linia environments w [tool.uv]
jest load-bearing, ale nieudokumentowana. Weszła commitem 0f3f049e0
o wiadomości „Prepare fix, maybe" (2025-10-14) — razem z urllib3>=2.2.3
i vcrpy>=6.0.2, i to był właśnie ten fix, tylko nigdzie nieopisany.

Powód: uv robi universal resolution — jeden lock ma być poprawny dla
każdego interpretera, także nigdy nieuruchamianego. vcrpy 6.0.2 miało:

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

Gałąź PyPy żądała urllib3<2, nie do pogodzenia z urllib3>=2.2.3.
Wykluczenie PyPy kasuje tę gałąź.

Czy dziś jeszcze potrzebne — sprawdzone, nie zgadnięte. Przeskanowany
cały graf z uv.lock: 364 pakiety z rejestru (3 pominięte jako
editable/git), zero błędów pobrania metadanych. Warunki == "PyPy"
są w czterech miejscach:

Pakiet	Wymaganie	Bramka
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 są uśpione — te extras nie są włączone; brotlipy,
munkres ani mypy nie występują w uv.lock, a z fonttools bierzemy
wyłącznie [woff]. vcrpy 8.3.0 nie ma już swojego warunku.

Zdjęcie wykluczenia daje dziś dokładnie te same wersje (367 pakietów,
zero różnic). Zostaje mimo to jako tanie ubezpieczenie — kosztuje 13 linii
resolution-markers, a bez niego cryptography, pynacl i
uvicorn[standard] i tak odzyskują markery PyPy na krawędziach do
cffi/uvloop, więc lock nie robi się prostszy.

Dodatkowo dolna granica python_version >= '3.10' → >= '3.11'. Była
martwa (przecięcie z requires-python = ">=3.11,<3.15" i tak dawało 3.11),
ale mylnie sugerowała wsparcie dla 3.10. uv.lock po tej zmianie jest
bit w bit identyczny — zmiana czysto opisowa.

Weryfikacja

Bramka	Wynik
pip-audit (komenda z CI)	✅ No known vulnerabilities found (przed: 4 CVE)
uv lock --check (uv 0.11.29, jak w CI)	✅ bez dryfu
bin/check-ruff-pin-sync.py	✅ exit 0
ruff 0.16.3 vs 0.16.6 na tym drzewie	✅ identycznie — 122 errors, ten sam rozkład reguł, 124 pliki do reformatu (dług pre-existing na dev, nietknięty)
yarn install --frozen-lockfile	✅ integrity OK, node_modules raportuje 7.1.5
zizmor na zmienionych workflowach	✅ No findings
actionlint	7× SC2086 w release-candidate.yml — identycznie na dev (pre-existing, patrz niżej)
make tests (pełne, lokalnie)	✅ 9438 passed, 4 skipped, 1 xfailed (4:30) · 157 passed, 1 skipped — Playwright (1:40) · 112 passed / 9 plików — vitest · EXIT: 0
make tests-without-playwright na finalnym locku	✅ powtórzone po przeliczeniu locka przez uv@0.11.29

Zestaw zainstalowanych pakietów przed i po przeliczeniu locka jest
identyczny (uv pip list --format=freeze — zero różnic), więc pełny
przebieg make tests powyżej pozostaje ważnym dowodem; mimo to suita
Pythona została powtórzona na finalnym locku.

.test_durations celowo nie jest w tym PR — make tests odświeża go
przez --store-durations, ale to 5679 linii szumu z timingów tej maszyny,
bez związku z aktualizacją zależności.

Uwaga poboczna (NIE naprawiane w tym PR)

Wyciszenie SC2086 w .github/actionlint.yaml jest zawężone do
tests.yml, ale ten sam zamierzony wzorzec $COMPOSE_FILES dorobił się
w międzyczasie release-candidate.yml. Hook actionlint failuje więc
lokalnie każdemu, kto dotknie tego pliku — findings są pre-existing
(7 na dev, 7 tutaj), a actionlint nie jest checkiem CI (job lint
odpala po nazwie tylko ruff i ruff-format), więc tego PR-a nie
blokuje. Poszerzenie wyciszenia to osobna zmiana.

Zamknięcie PR-ów dependabota

Po zmergowaniu dependabot sam zamknie #807, #806, #805, #799, #798,
#794, #790 i #788 — wykryje, że zależności są już podniesione na gałęzi
bazowej. Ręczne zamykanie nie jest potrzebne.

🤖 Generated with Claude Code

https://claude.ai/code/session_011aZqYiv56cwAudG2CPS3k5