feat(dane): mechanizm rekordów-pułapek (canary) — wykrywanie wycieku baz (DAN-26)

Zabezpieczenie DETEKCYJNE (nie prewencyjne): kilka unikalnych, wiarygodnie
wyglądających rekordów-pułapek w bazach. Nie zmieniają interpretacji (odsiewamy
je z wyników), ale jeśli pojawią się w cudzej kopii — są dowodem pochodzenia, a
przy wariancie na kopię — wskazują ŹRÓDŁO wycieku.

`canary.py`: pułapkę rozpoznajemy po MARKERZE (unikalny ciąg z ENV, nieobecny w
realnych danych). `screen(rows, query_value)`:
- ODSIEWA rekordy z markerem z wyników — i to na WYJŚCIU z warstwy danych
  (`/search`), więc nie dotrą wyżej ani do promptu LLM (LOG-30), niezależnie od
  dostawcy (Excel/SQL);
- TRIPWIRE: gdy zapytanie celuje wprost w marker (enumeracja bazy, nie liczenie
  horoskopu) → log warning.
Bez `CANARY_MARKERS` — przezroczyste, zero kosztu dla normalnego ruchu.

Rejestr wariant→kopia (traitor tracing) i wstrzyknięcie do REALNYCH baz to krok
właściciela (poza kodem — nie ruszamy kupionych plików automatycznie);
instrukcja: docs/canary-registry.md. Mechanizm zbudowany i przetestowany na
syntetycznych pułapkach.

Testy: +7 (przezroczystość bez markerów, odsiewanie, tripwire, marker w dowolnym
polu, endpoint odsiewa przed zwrotem). Pierwsze testy w usłudze `data`.

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

docs/canary-registry.md

@@ -0,0 +1,58 @@
+# Rekordy-pułapki (canary) — instrukcja (DAN-26)
+
+Zabezpieczenie **detekcyjne**: nie zapobiega wyciekowi baz, ale pozwala go
+**wykryć** i wskazać **z której kopii** wyciekł. Bazy są kupione i są rdzeniem
+produktu — jeśli krążą gdzie indziej, chcemy to udowodnić.
+
+Mechanizm żyje w warstwie danych (`services/data/app/canary.py`) i działa na
+wyjściu z `/search`, więc pułapki **nie docierają** ani do użytkownika, ani do
+promptu LLM (wymóg LOG-30) — niezależnie od dostawcy (Excel/SQL).
+
+## Jak to działa
+
+1. **Marker** — unikalny ciąg, który nie występuje w realnych danych, wpleciony
+   w kilka wiarygodnie wyglądających rekordów-pułapek w bazach (np. w polu
+   znaczącym: `Ve Tau ASTROLOLO-CANARY-7f3a9`).
+2. **Odsiewanie** — warstwa danych wykrywa rekord z markerem i usuwa go z wyników,
+   zanim opuszczą usługę. Interpretacje i prompty są czyste (log `info`).
+3. **Tripwire** — jeśli zapytanie **celuje wprost** w marker (ktoś enumeruje bazę,
+   a nie liczy horoskopu), leci `warning` — sygnał podejrzanego zachowania.
+
+## Konfiguracja (per wdrożenie)
+
+Zmienne środowiskowe usługi `data`:
+
+| Zmienna | Znaczenie |
+|---|---|
+| `CANARY_MARKERS` | markery oddzielone przecinkami (kilka na wariant) |
+| `CANARY_VARIANT` | etykieta wariantu tego wdrożenia (np. `prod-2026`, `partnerX`) |
+
+Bez `CANARY_MARKERS` mechanizm jest **przezroczysty** (zero kosztu). Markery są
+sekretem — trzymaj je jak `astrololo-auth` (poza repo GitOps), przez `secretKeyRef`.
+
+## Rejestr wariant → kopia (traitor tracing)
+
+Sedno atrybucji: **każda dystrybuowana kopia baz dostaje inny zestaw pułapek**,
+a Ty trzymasz mapę, który wariant trafił dokąd. Gdy zobaczysz pułapkę w cudzej
+kopii → sprawdzasz marker w rejestrze → wiesz, skąd wyciekła.
+
+Rejestr trzymaj **poza kodem i repo** (arkusz/menedżer sekretów po stronie ops),
+np.:
+
+| Wariant | Markery | Wdrożenie / odbiorca | Data |
+|---|---|---|---|
+| `prod-2026` | `…7f3a9`, `…b12c` | produkcja czernobog | 2026-08 |
+| `partnerX` | `…9de4`, `…0a1b` | kopia dla partnera X | 2026-08 |
+
+## Wstrzyknięcie pułapek do baz (krok właściciela)
+
+To robi właściciel na **realnych** plikach (kod tego nie robi — nie ruszamy
+kupionych baz automatycznie): dodać kilka rekordów-pułapek z markerem danego
+wariantu, w stylu nieodróżnialnym od prawdziwych wpisów. Kilka, wtopionych —
+łatwiej, gdy ktoś zna mechanizm, wyciąć jeden oczywisty niż wszystkie.
+
+## Granice
+
+Canary dowodzi pochodzenia tylko, gdy wyciek **zawiera** treść pułapki (pełna
+kopia — tak; parafraza — niekoniecznie). Nie wykrywa retencji *prawdziwej* treści
+u dostawcy LLM — od tego jest bramka LOG-32 i wniosek o Zero Data Retention.