fix(nginx): przepuść /.well-known/ (discovery OAuth) mimo blokady plików ukrytych

[mpasternak]

Problem

GET https://<host>/.well-known/oauth-authorization-server zwracał 403 od
nginksa na każdym wdrożeniu — mimo że serwer autoryzacji OAuth działał bez
zarzutu:

Endpoint	Status
/o/authorize/	302 → /accounts/login/ ✅
/o/token/	400 (czeka na parametry) ✅
/o/register/ (DCR)	201, poprawny client_id ✅
/.well-known/oauth-authorization-server	403 nginx ❌

Skutkiem było to, że klient MCP (bpp-mcp)
nie mógł wykonać discovery (RFC 8414) i logowanie padało na pierwszym kroku,
choć całe OAuth było gotowe do użycia.

Przyczyna

_bpp-locations.conf blokuje pliki ukryte:

location ~ /\. {
    deny all;
}

To regex, a regexy w nginksie mają pierwszeństwo przed zwykłymi prefiksami.
/.well-known/ zaczyna się od kropki, więc wpadał w tę regułę i żaden
prefiksowy location nie mógł go wyprzedzić.

Diagnoza potwierdzona z zewnątrz: losowa ścieżka pod /.well-known/ też
dawała 403 (a nie 404), co dowodzi, że blokuje nginx, a nie Django.

Naprawa

location ^~ /.well-known/ {
    limit_req zone=bpp_general burst=100 nodelay;
    try_files $uri @proxy_to_app;
}

Modyfikator ^~ stawia prefiks ponad regexami. /.well-known/ (RFC 8615)
to standardowa przestrzeń metadanych serwisu, a nie „plik ukryty" — leżą tam
metadane OAuth i security.txt. Django odpowiada 404 na nieznane ścieżki, więc
nic się nie odsłania, a .git/.env dalej łapie regex poniżej.

ACME nie był dotknięty

Sprawdzone osobno: po HTTP (port 80) /.well-known/acme-challenge/ zwraca 404,
nie 403. Blok port-80 w vhost.conf.template nie includuje
_bpp-locations.conf, więc reguła tam nie sięgała i walidacja Let's Encrypt
działała przez cały czas.

Test

Nowy blok 15d w istniejącym harnessie test_nginx_runtime — startuje
prawdziwy nginx:1.30.2 z pełnym łańcuchem entrypointów i fake appserverem,
po czym sprawdza obie strony kontraktu naraz:

• /.well-known/oauth-authorization-server musi dojść do appservera
  (asercja na echo ścieżki, nie na samo 200),
• /.git/config i /.env muszą dalej dostawać 403.

Druga asercja jest tu kluczowa: bez niej „naprawa" polegająca na skasowaniu
blokady plików ukrytych przechodziłaby jako zielona.

Weryfikacja:

• przed poprawką 15d pada (403 zamiast proxy),
• po poprawce 22/22 zielone,
• testy ACME (15c) bez zmian.

Uwaga wdrożeniowa

Do czasu wdrożenia tej zmiany bpp-mcp radzi sobie fallbackiem na /o/*
(bpp-mcp#…), ale to obejście po stronie
klienta. Natywny przycisk „authorize" w Claude (tryb HTTP) wymaga tej
poprawki — tam discovery robi sam klient Claude i fallbacku nie ma.