Changelog

Der Melder stufte allein nach locked gegen published ein und fragte nie, ob ein
Repositorium ueberhaupt ausbringbar ist — dieselbe Fehlerklasse, die CLAUDE.md
fuer die Pipelines-Zeile festhaelt (zaehlt Dateien, nie laufende Dienste).

Gemessen fuehrte er platform/internal als BEHIND: nie ausgebracht, nie eine Kette
gehabt, seit 2026-08-22 stillgelegt. Zwei belegte Schaeden — es entstand echte
Pflege-Arbeit daran (zwei Fundament-Pin-Commits am 2026-08-21 an einem
Repositorium ohne fachlichen Commit seit 2024-02-19), und --apply haette eine
Kette ausgeloest, die es gar nicht gibt.

Ein Repositorium mit RETIRED*.md im Wurzelverzeichnis faellt jetzt VOR der
Einstufung heraus — damit zugleich aus BEHIND, aus BEDINGT und aus der
Modul-Zaehlung. Es wird als eigene Zeile AUSGEWIESEN, nie still verschluckt
(ein unsichtbarer Ausschluss waere dieselbe Fehlerklasse in der anderen
Richtung); die JSON-Form traegt es ebenfalls.

--apply ist damit MITgehaertet und braucht keinen zweiten Waechter: die
Ausloese-Menge faellt ueber vier filter-Stufen aus derselben Liste, wer aus ihr
faellt, kann sie nicht erreichen. Eine Probe nagelt genau das fest.

Verify: Trockenlauf 24 -> 23 Kandidaten, platform/internal nur noch in der
Stillgelegt-Zeile, Negativ-Kontrolle domains/audit/api weiterhin drin. Neue
Probenreihe 7 Proben je Richtung; alle redeploy-Reihen 49/49.
Die 8 Fehlschlaege der vollen Reihe sind VORBESTEHEND — mit engem Rueckbau nur
dieser Datei nachgemessen: identische acht Titel auch ohne die Aenderung.

URSACHE, reproduziert statt vermutet: die Scan-Wurzel kam aus `process.cwd()`, und der
Verzeichnis-Durchlauf verschluckt einen fehlenden Pfad still (`catch { return }`). Aus einem
beliebigen anderen Verzeichnis gefahren lieferte der Befehl deshalb `affected: []` — bei
FUNKTIONIERENDER Registry-Abfrage und ohne jeden Hinweis.

Das ist byte-genau die Form des Befundes vom 2026-08-21 (`affected: []` bei
`published: 2026.444.0`) und beantwortet die Frage des Briefes, welche der beiden Stufen
versagt: die KANDIDATEN-Erkennung, nicht der Versions-Vergleich. Waere es der Vergleich
gewesen, haetten 24 Zeilen mit `UNKNOWN` dagestanden.

Drei Aenderungen:
- `defaultScanRoot()` nutzt `getMonorepoRoot()` (leitet aus dem EIGENEN Ort ab) statt cwd —
der kanonische Helfer, den drei andere Befehle bereits nutzen.
- `scanEntityConsumers` WIRFT, wenn unter der Wurzel keiner der vier Ordner liegt. Eine leere
Menge ist hier nie eine Entwarnung; ohne den Waechter ist eine falsche Wurzel von einem
leeren Monorepo nicht zu unterscheiden.
- Ehrliche Zaehlung in Zusammenfassung UND json: `Kandidaten: N · davon BEHIND: M · CURRENT ·
UNBEKANNT`. „0 von 0" und „0 von 24" sahen bisher gleich aus — genau dieser Unterschied war
der ganze Befund. Plus ein ausdruecklicher Hinweis, wenn die veroeffentlichte Fassung nicht
lesbar war (dann ist jeder Stand UNBEKANNT, nicht CURRENT).

Flip-Probe (test/redeploy-entity-consumers-scan-root.test.mjs, 3 Proben inkl.
Negativ-Kontrolle): vorher liefert `scanEntityConsumers(<leeres Verzeichnis>)` still `[]`,
nachher wirft es. Suite-Ebene: Grundlinie 9 Fehlschlaege, danach 8 — die 8 sind vorbestehend
und fremd (Renderer, coord-admin, Formatter), meine Datei kippt von rot auf gruen.

Ende-zu-Ende aus /tmp gefahren: 24 Kandidaten, 24 BEHIND, `custom-functions-worker` gefuehrt.