docs(decision): D-108 berichtigen — die Ankerliste wird geöffnet, nicht festgeschrieben

[cubetribe]

Berichtigt die Prämisse von D-108 und fasst die Entscheidung in der Sache neu.
Reine Dokumentation — der Code wird in diesem PR nicht angefasst.

Was falsch war

Die Erstfassung von D-108 (2026-08-17) behauptete, ConstructionSystem lasse
bereits jedes eigene Gebäude als Bauanker gelten, und wollte diesen Zustand
lediglich aussprechen. Der Code tut das nicht:

// ConstructionSystem.IsInsideBuildInfluence
if (def.Role != UnitRole.HQ && def.Role != UnitRole.Storage && def.Role != UnitRole.Power) continue;

Anker sind HQ, Lager und Kraftwerk. Kaserne, Fahrzeugfabrik, Raffinerie,
Radar, Labor und Verteidigungsplattform erweitern die Zone nicht. D-104 Punkt 2
sagt genau das, wörtlich: „Ein Neubau braucht ein eigenes, lebendes und
fertiggestelltes HQ, Lager oder Kraftwerk in höchstens acht Zellen Abstand."

Der Fehler entstand, weil der Docstring von BuildInfluenceRadiusCells und
Issue #92 von einem „eigenen Bauanker" sprechen, ohne die Rollenliste zu nennen —
und die Implementierung vor der Beschlussfassung nicht gelesen wurde.

Gefunden hat ihn der ausführende Agent beim Umsetzen von Paket 21.1. Er hat
angehalten und nachgefragt, statt den Widerspruch selbst aufzulösen. Das ist
genau der Weg, den die Vorrangregel des Auftrags verlangt, und er hat hier eine
Entscheidung auf falscher Grundlage abgefangen.

Was jetzt gilt

Der Inhaber hat in Kenntnis der tatsächlichen Lage neu entschieden: nicht die
Bestandsregel festschreiben, sondern die Ankerliste öffnen. Jedes eigene,
lebende und fertiggestellte Gebäude wird Anker; die Rollenprüfung entfällt.

Damit ist D-108 keine Festschreibung mehr, sondern eine Verhaltensänderung:

• RulesHash64 bewegt sich
• die Determinismus-Baselines werden rot
• der gepinnte Ausgang der kanonischen KI-Partie (CanonicalAiOutcomeTests,
  Einheitenstrang) bewegt sich mit

Also: eigener Regel-PR, zweiter PR für die Baselines, und ein mit @arn-c0de
abgestimmtes Merge-Fenster, bevor irgendetwas davon aufmacht.

Bewusst in Kauf genommen und im D-ID vermerkt: ab jetzt kann sich ein Spieler mit
einer Kette billiger Gebäude über die Karte schieben, weil auch Kaserne und
Verteidigungsplattform ankern. In C&C etabliertes Verhalten, und im Zusammenspiel
mit 21.6/21.7 der Weg, auf dem ein umkämpftes Feld überhaupt erschlossen wird.

Die Messung ist erledigt — beide Konstanten bleiben

Aus Paket 21.1, nachgerechnet:

MinimumBuildingDistanceCells	Gebäude in der Startzone
2 (Ist, D-104)	15
1	23 (+53 %)
0	23 — identisch zu 1, weil die Footprint-Belegung Abstand unter 1 ohnehin verbietet

Der einzige wirksame Hebel wäre 2 → 1, und beide Konstanten bleiben
unverändert. Die Zahl weist die gemeldete Enge nicht als Abstandsproblem aus,
und die 15 sind ohnehin nur eine untere Schranke für die Anfangszone — jeder
Anker schiebt die Grenze mit.

Nachgezogen

• D-108 komplett neu gefasst, mit sichtbarem Abschnitt „Berichtigung"; der
  Fehler wird nicht stillschweigend überschrieben
• Paket 21.1 im Sprint: von Dokumentationspaket zu Verhaltensänderung, mit
  Messergebnis, Regeländerung und zweifachem Docstring-Nachzug
• R-2, R-3, Versionsrelevanz, „Fertig wenn" im Sprint sowie Pakettabelle
  und Merge-Fenster-Hinweis im Auftrag
• Changelog-Zeilen unter [Unreleased]

Nachweis

python3 .github/scripts/check_docs.py grün (183 Markdown-Dateien). Kein
Spielcode berührt, keine Baseline bewegt.