feat(astroklient): pule plików per konto i izolacja od produkcji (PRE-29)

Demo ma być rozdawane szeroko i różnym osobom, więc pierwsza wersja — jedno konto
na produkcyjnej warstwie danych — nie nadawała się do użycia: każdy dostawałby
dostęp do oryginalnych baz, a wgrania jednego klienta widzieliby wszyscy.

IZOLACJA OD PRODUKCJI. Warstwa danych i logiczna demo są osobne (manifesty w repo
deploy). Osobna musi być TEŻ LOGICZNA, bo zna ona jeden adres warstwy danych —
demo korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.

PULE PER KONTO w warstwie danych. Zapytanie i lista plików niosą nazwę puli;
puste = cały udział, czyli produkcja działa dokładnie jak dotąd i o pulach nic
nie wie. Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
w nazwie katalogu — „../..” albo ukośnik wyprowadziłyby zapytanie wprost do cudzych
baz, więc sito ZAMIENIA podejrzane znaki zamiast ufać, że nikt ich nie poda.

PULA MUSI BYĆ W KLUCZU CACHE ZAPYTAŃ. Bez tego wynik policzony dla jednego konta
trafiłby z cache do drugiego — cicha wymiana treści baz między klientami,
niewidoczna w logach i nie do wykrycia z zewnątrz. Osobny test tego pilnuje.

PULA WYNIKA Z LOGINU, nigdy z żądania. Klient warstwy logicznej jest budowany
per żądanie i związany z pulą zalogowanej osoby; gdyby nazwa przychodziła
z formularza, wystarczyłoby podstawić cudzy login. Test wysyła `tenant`, `user`
i `login` w polach formularza i sprawdza, że nie mają na nią wpływu.

Pulę wstrzykujemy w INSTANCJĘ klienta, nie w sygnatury metod. Argumentem trzeba
by ją przeprowadzić przez protokół DataSource i build_report — kod, który o kontach
nie ma prawa nic wiedzieć — a każde nowe wywołanie byłoby okazją, żeby o nią
zapomnieć i sięgnąć nie tam.

Konta demo to lista `login:sekret` (DEMO_USERS), bo jedno wspólne konto oznaczałoby
wspólną pulę. Format i skrypt haseł te same, co w głównej aplikacji.

Pula klienta to JEDEN KATALOG, więc przejście na pełną wersję nie oznacza utraty
wgrań — procedurę importu opisuje runbook w repo deploy.

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

services/astroklient/README.md

@@ -15,29 +15,42 @@ a nieobecność to dwie różne rzeczy**: tutaj nie ma tras, nie ma szablonów,
 nawet metod w kliencie warstwy logicznej. Demo można komuś oddać, nie oddając przy
 okazji kodu reszty programu.
 
-## ⚠️ Demo pracuje na produkcyjnej warstwie danych
+## Izolacja: własne dane, pula na konto
 
-Świadoma decyzja właściciela. Konsekwencje, żeby nie było niespodzianek:
+```
+astroklient  →  logic-demo  →  data-demo  →  udział astrololo-demo (pusty na starcie)
+                                              └── klientA/   ← pula konta
+                                              └── klientB/   ← pula konta
+```
 
-* **kto ma dostęp do demo, czyta oryginalne bazy interpretacyjne** — czyli rdzeń
-  produktu, którego pilnują LOG-32, DAN-25 i PRE-27,
-* **pliki wgrane przez demo trafiają do produkcyjnego zbioru baz** i od razu biorą
-  udział w wyszukiwaniu, także w pełnej aplikacji.
+**Oryginalne bazy interpretacyjne są dla demo nieosiągalne.** Nie chodzi
+o uprawnienia: demo ma własną warstwę danych, pracującą na osobnym udziale.
+Osobna jest też warstwa logiczna, bo zna ona JEDEN adres warstwy danych — demo
+korzystające z produkcyjnej logiki i tak trafiłoby na produkcyjne bazy.
 
-Dlatego konto astroklienta jest **osobne** (`DEMO_USER` / `DEMO_PASSWORD`): demo
-odcina się jedną zmienną środowiskową, bez ruszania kont głównej aplikacji i bez
-zmiany hasła komukolwiek.
+**Każde konto ma własną pulę** plików: swój podkatalog na tym udziale. Konta nie
+widzą swoich baz nawzajem ani w liście, ani w wynikach wyszukiwania. Dlatego demo
+można rozdawać szeroko.
 
-Jeśli demo ma trafić do kogoś spoza kręgu zaufania, właściwą odpowiedzią jest
-osobna warstwa danych z pustym udziałem — nie jest to dziś zrobione.
+Pula bierze się **z loginu zalogowanej osoby** i z niczego innego. Gdyby
+przychodziła z żądania, wystarczyłoby podstawić cudzy login, żeby czytać cudze
+bazy — osobny test wysyła `tenant`, `user` i `login` w formularzu i sprawdza, że
+nie mają na nią wpływu.
+
+Nazwa puli przechodzi przez sito dopuszczające wyłącznie znaki bezpieczne
+w nazwie katalogu: `../..` czy ukośnik wyprowadziłyby zapytanie poza udział.
+
+**Pula klienta to jeden katalog**, więc przejście na pełną wersję nie oznacza
+utraty wgrań — procedura importu jest w runbooku wdrożenia (repo `deploy`,
+`astrololo/README-astroklient.md`).
 
 ## Konfiguracja
 
 | zmienna | znaczenie |
 |---|---|
 | `LOGIC_URL` | adres warstwy logicznej (domyślnie `http://localhost:8001`) |
-| `DEMO_USER` | login (domyślnie `demo`) |
-| `DEMO_PASSWORD` | hasło — jawne albo hash `scrypt$sól$hash`. **Puste = aplikacja stoi otwarta** i mówi o tym głośno przy starcie |
+| `DEMO_USERS` | konta jako `login:sekret`, po przecinku. Sekret jawny albo hash `scrypt$sól$hash`. Każdy login = osobna pula plików |
+| `DEMO_USER` / `DEMO_PASSWORD` | pojedyncze konto — zgodność wstecz, działa gdy `DEMO_USERS` jest puste. **Brak obu = aplikacja stoi otwarta** i mówi o tym głośno przy starcie |
 | `INTERNAL_TOKEN` | token międzywarstwowy (LOG-32) — ten sam co reszta usług |
 | `LINK_KEY_PRESENTATION_LOGIC` | klucz szyfrowanego łącza (PRE-16) — ten sam co prezentacja |
 | `RATE_LIMIT_PER_MIN` | limit żądań na adres, domyślnie 60; `0` wyłącza |