docs(pliki): runbook otwarcia udziału z bazami na zapis

Decyzja właściciela: idziemy wariantem, w którym udział z bazami staje się
zapisywalny. DAN-25 dawał gwarancję, że baz nie da się zmienić przez NFS, a
DAN-27 tę gwarancję z definicji znosi — nie da się mieć obu naraz. Runbook mówi
to wprost i wylicza, co z zabezpieczeń zostaje.

mapall_user: root mimo drwxrwxrwx na katalogu. Samo ro: false wystarczyłoby do
zapisu, bo zmapowany nobody mieści się w prawach „innych" — ale nowe pliki
należałyby wtedy do nobody, a istniejące bazy do root. Mieszana własność zemści
się przy pierwszym zaostrzeniu praw.

Krok 3 z ostrzeżeniem, że rollout restart nie wystarcza: pody się na chwilę
nakładają, więc montowanie NFS nie zostaje bez użytkownika i nowy dziedziczy
uprawnienia sprzed zmiany eksportu. To kosztowało najwięcej czasu przy udziale
astrololo-state.

Krok 4 sprawdza wyszukiwanie JAKO OSTATNI I NAJWAŻNIEJSZY punkt — to jedyne
miejsce, w którym ta zmiana mogłaby przejść niezauważona: przejście na rejestr
plików mogłoby wyłączyć wszystkie bazy i wyglądałoby to jak pusta baza, a nie
jak zepsuty deploy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

astrololo/README.md

@@ -23,6 +23,12 @@ Ten plik **celowo nie jest w `kustomization.yaml`**: resource stoi w ns `argocd`
 (poza namespace docelowym aplikacji), a to konfiguracja kontrolera, który wdraża tę
 aplikację — nakładamy go ręcznie, w repo trzymamy dla odtwarzalności i historii.
 
+## Pliki baz — udział otwarty na zapis (DAN-27)
+
+Runbook: **[README-pliki.md](README-pliki.md)**. Ekran „Pliki" wymaga zapisu do
+udziału z bazami, więc znosi gwarancję z DAN-25, że baz nie da się zmienić przez
+NFS. Co zostaje z zabezpieczeń i jak to wdrożyć — w runbooku.
+
 ## ⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem
 
 Aplikacja wystawia treść **oryginalnych baz interpretacyjnych**, dlatego wymaga