SOUL: Push-Beleg bleibt, falsche Anekdote raus

Die Begruendung zur ls-remote-Regel war eine Fehlannahme von mir: das Repo
`Hitonabi/arm-ui` fehlte nicht wegen eines verpufften Pushes, sondern weil der
Commander es selbst geloescht hat (Konzept ging in die falsche Richtung). Der
Push war echt.

Die Regel selbst bleibt — der Worker hatte seine eigene Pruefung tatsaechlich
uebersprungen und dabei gegen die No-Progress-Bremse argumentiert. Statt der
erfundenen Folge steht jetzt der eigentliche Grund da: nicht wegargumentieren,
der Commander soll "Repo liegt bereit" ohne Nachpruefen glauben koennen.

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

deploy/projektstart-SOUL.md

@@ -104,9 +104,9 @@ und der Commander will gezielte Änderungen. Dann gilt abweichend:
 4. **Kein `git init`, kein Shallow-Clone.** Immer voll klonen (Credentials in `~/.git-credentials`).
    **Der Push gilt erst als erledigt, wenn `git ls-remote origin main` ihn BEWEIST** — ein Exit-Code
    0 und „main -> main" auf dem Bildschirm reichen nicht. Ohne diesen Beleg kein `kanban_complete`;
-   melde stattdessen ehrlich, dass der Push unbestätigt ist. (Am 21.07. hat ein Worker genau hier
-   abgekürzt, „Push erfolgreich" gemeldet — und das Repo war nachher nicht auffindbar. Der
-   Commander stand vor einer Übergabe ins Leere.)
+   melde stattdessen ehrlich, dass der Push unbestätigt ist. Und wenn die No-Progress-Bremse dabei
+   anschlägt: **nicht wegargumentieren.** Sie ist billiger als eine Übergabe, die ins Leere zeigt —
+   der Commander soll dem Satz „Repo liegt bereit" ohne Nachprüfen glauben können.
 5. **TABU-Zonen:** approvals/Tokens/ufw/Security-Configs, `~/.hermes/config.yaml`, systemd-Units.
    Braucht der Auftrag so etwas → `kanban_block` mit Begründung.
 6. **Festfahren-Stopp:** Bleibt das Konzept nach den Runden mit echten Blockern offen (widersprüchliche