docs(kb): oznacz decyzje (a)-(h) wiki-kompilat-recon jako zatwierdzone, usuń wklejone bajty NUL

Operator zatwierdził pakiet (a)-(h) z §10 w całości bez zmian 2026-08-27.
Plik zawierał 4 dosłowne bajty NUL (offsety ~37383/37891/41544/47333) —
wklejki z SELECT-ów po korpusie mailowym — które sprawiały, że narzędzia
tekstowe (grep) traktowały plik jako binarny; usunięte, treść w tych
miejscach pozostaje czytelna (puste `` obok `�` — oba demonstrują literalnie
bajt, którego dotyczą).

kb/audits/wiki-kompilat-recon-2026-08-26.md

@@ -3,7 +3,7 @@ okf: "0.1"
 type: audit
 visibility: private
 status: active
-updated: 2026-08-26
+updated: 2026-08-27
 as_of: 2026-08-26
 links:
   - ../phases/kb-m5-faza3.md
@@ -663,7 +663,7 @@ wiki-kompilat:
 - **NUL w `entities` jsonb jest poważniejszy strukturalnie** — jeśli sesja
   kompilująca odpytuje `entities` bezpośrednio (nie tylko `document_chunk.text`),
   NUL bajt w jsonb może wywrócić parser po stronie klienta (Pythonowy
-  `json`/`asyncpg` różnie reaguje na `` w zależności od ścieżki). To
+  `json`/`asyncpg` różnie reaguje na `` w zależności od ścieżki). To
   **nie zostało zweryfikowane w tym reconie** (nie testowałem odczytu takiego
   wiersza) — flaguję jako `[do weryfikacji]`, nie jako potwierdzony problem.
 
@@ -671,7 +671,7 @@ wiki-kompilat:
 (charset/NUL) — skala nie uzasadnia opóźnienia PoC. Warto natomiast, żeby
 lint (inwariant 3) przy pierwszym uruchomieniu zrobił **jednorazowy skan**
 `document_chunk`/`envelope.entities` pod kątem znaków zastępczych
-(`<60>`) i `` w źródłach, które faktycznie zasiliły PoC (17 stron
+(`<60>`) i `` w źródłach, które faktycznie zasiliły PoC (17 stron
 §3) — tanie zabezpieczenie, żeby nie odkryć problemu dopiero przy spot-checku
 tygodnie później.
 
@@ -721,7 +721,7 @@ Zależy od Etapu 1 (mechanizm zweryfikowany). Zakres:
    semantyczna to zadanie dla CC, nie dla skryptu; skrypt robi tylko
    pre-filtr kandydatów).
 2. Rozszerzenie o pozostałe encje z §3 (do 17), plus jednorazowy skan pod
-   kątem `<60>`/`` (§8 „follow-upy fazy mailowej") na źródłach, które
+   kątem `<60>`/`` (§8 „follow-upy fazy mailowej") na źródłach, które
    faktycznie zasiliły te strony.
 3. **DoD etapu**: `lint.py` uruchamiany ręcznie (nie timer — zgodnie z §4,
    automatyzacja poza zakresem), raport w `_meta/lint-reports/`, zero
@@ -743,6 +743,11 @@ Zależy od Etapu 1 (mechanizm zweryfikowany). Zakres:
 
 ## 10. Punkt 9 — Decyzje operatora
 
+> **Status: (a)-(h) ZATWIERDZONE przez operatora w całości 2026-08-27, bez
+> zmian** — wzorzec identyczny jak decyzje (a)-(g) w `mail-sync-2026-08-06.md`
+> (zatwierdzone 2026-08-06 w całości, patrz `kb-m5-faza-mailowa.md` nagłówek
+> statusu).
+
 Wzorzec (a)-(g) z `kb/audits/mail-sync-2026-08-06.md` §4.
 
 ### (a) Wersja OKF dla `kb-wiki`: pin v0.1 (jak pilot) vs start od razu na v0.2
@@ -822,7 +827,7 @@ mini-śledztwa kontekstu firmy.
 ### (h) Follow-upy fazy mailowej (charset/NUL) — nie blokują, jednorazowy skan przy Etapie 2
 
 **Rekomendacja:** (§8) nie opóźniać PoC na R1–R3 z incydentu 20-dni-ciszy;
-dopisać jednorazowy skan `<60>`/`` do zakresu Etapu 2 (lint), nie jako
+dopisać jednorazowy skan `<60>`/`` do zakresu Etapu 2 (lint), nie jako
 osobny, wcześniejszy krok.
 
 ---
@@ -843,4 +848,5 @@ zweryfikować mechanizm entity-resolution na trudnym przypadku — aliasach —
 zanim zainwestuje się w skalę), z jawnym odłożeniem pipeline'u eskalacji i
 integracji retrievalu produkcyjnego do kolejnych etapów.
 
-Do decyzji operatora: (a)-(h) w §10.
+Decyzje: (a)-(h) w §10 — **ZATWIERDZONE przez operatora w całości 2026-08-27,
+bez zmian.**