Tree Gen 1.46.0: Halbkugel-Bueschel, groessere Baeume, Spitzen-Deckung

1) NEUE BAUFORM: Blattwerk als Halbkugel-Cluster
   Jeder gestreute Punkt ist jetzt ein Cluster-ZENTRUM, die Cards sitzen auf
   der oberen Halbkugel darum herum. Untere Haelfte weggelassen - von unten
   sieht man die Krone gegen den Himmel, das waere Overdraw fuer nichts.

   Zwei Annahmen kassiert die Messung: GeometryNodeMeshIcoSphere liefert bei
   Subdivisions 0 UND 1 dasselbe Ikosaeder, ein Cluster hat SECHS Cards statt
   der angenommenen 26. Und die Stufen-Ziele muessen Cluster-Vielfache sein
   (26/78/208/390) - S1 stand auf 10, unter der kleinsten Einheit, die Regelung
   waere nie konvergiert. S4 ist seither geregelt statt "volle Dichte":
   ungeregelt lieferte die Schale 2706 Cards an der Eiche.
   ast_id ueberlebt Instanzieren + Realize, an den Cards nachgewiesen.

2) SPITZEN-DECKUNG: zwei echte Ursachen, beide vorher nur vermutet
   - Der Kronenansatz-Filter stand auf 25 % der Baumhoehe, die Tanne setzt ihre
     Aeste ab 12 % an: bei 5 von 22 Aesten lag das aeussere Fuenftel KOMPLETT
     unter dem Filter. Jetzt auf den Branch Start der Art gedeckelt.
   - Haengende Spitzen fielen unter den Filter. Jetzt zaehlt der ANSATZ des
     Astes (anchor) mit, nicht nur die Punkthoehe.

   Ergebnis: Eiche/Baum 100 %, Weide 100/90, Obstbaum 100/93, Tanne 86/86,
   Birke 100/72. Die 85-%-Schwelle der Spielseite ist damit erreicht, ohne dass
   die Rinden-Ersparnis noetig war.

   Die Metrik war zweimal falsch: der Abstand zur Card-MITTE ist zu streng -
   eine 0.85-m-Card deckt die Spitze auch aus 0.45 m Abstand, bei 1.9 m
   Astlaenge kamen so 24 % heraus, obwohl das Polster genau auf der Spitze sass.
   Jetzt zaehlt Deckung, nicht Abstand.

3) GROESSERE BAEUME, proportional skaliert
   Eiche 9.3 m, Birke 11.0, Tanne 13.0, Weide 7.0 - Hoehe, Astlaenge und
   Stammradius zusammen, sonst wird der Baum eine Stange mit Minikrone. Alle
   unter dem 4300er-Deckel; die Birke brauchte eine Card-Deckelung auf 340.

4) Kugel-Kennwert RELATIV, Bbox-Kriterium ersetzt
   Die Schalen schieben jede Card in ALLE Richtungen vom Ast weg: die Krone
   gewinnt ringsum Breite, in der Hoehe nur oben. Der Obstbaum fiel dadurch von
   1.35-1.47 auf 0.95-1.23, ohne dass an seiner Form etwas falsch war.

   Zwei Hypothesen sind an der Messung gescheitert, beide klangen plausibel:
   den Kappen-Faktor entkoppeln (0.93-1.14 -> 0.95-1.23) und den Kappen-Radius
   vergroessern (59-77 % -> 58-75 %). Der Radius waechst in alle Richtungen und
   verschiebt das Verhaeltnis deshalb kaum. Was wirkt, ist die Kronenbreite.

   Schranke jetzt relativ: hoechstens 65 % des Eichenwerts aus DEMSELBEN Lauf.
   Eine neue Konstante haette bei der naechsten Bauform dasselbe Schicksal.
   LEAF_CLUSTER_PRESET bleibt trotzdem eine eigene Tabelle - Card-Grobheit und
   Polster-Abstand sind zwei verschiedene Fragen.

   "Bbox-Mitte == 0" ist raus. Nachgemessen ueber drei Presets und drei Seeds:
   Stammachse 0.0000 m in allen neun Faellen, Bbox-Exzentrik 0.08-0.39 m mit
   dem Seed streuend, 3-13 % des Kronenradius. Eine Verschiebung traefe den
   Stamm mit und waere ueber die Seeds konstant - es ist Kronen-Schieflage.
   An seine Stelle tritt der Bounds-Radius, an dem das Culling haengt, geprueft
   gegen die Blender-Messung statt gegen eine Konstante.

27 Tests bestehen.

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

README.md

@@ -702,6 +702,84 @@ Gegenprobe ohne die Boden-Klemmung: vier Fehler.
 Drei bestehende Tests zaehlten die Huelle als Render-Mesh mit und schlugen zu
 Recht an - sie filtern jetzt `UCX_`.
 
+### Blattwerk als Halbkugel-Bueschel, und groessere Baeume
+
+Drei Aenderungen, die zusammengehoeren.
+
+**Neue Bauform.** Die Cards sassen einzeln auf der Astkurve - aus der Naehe sah
+man deshalb nackte Ast-Enden mit einem Mini-Bueschel daran. Jetzt wird jeder
+gestreute Punkt ein CLUSTER-ZENTRUM, und die Cards sitzen auf der oberen
+Halbkugel darum herum. Die Astspitze verschwindet im Polster, weil das Zentrum
+auf ihr liegt. Untere Halbkugel weggelassen: von unten sieht man die Krone
+gegen den Himmel, das waere die Haelfte des Overdraws fuer nichts.
+
+Zwei Annahmen kassiert die Messung: `GeometryNodeMeshIcoSphere` liefert bei
+Subdivisions 0 UND 1 dasselbe Ikosaeder - ein Cluster hat **sechs** Cards, nicht
+26. Und die Stufen-Ziele muessen Cluster-Vielfache sein (26/78/208/390): S1
+stand auf 10, unter der kleinsten Einheit, die Regelung waere nie konvergiert.
+S4 ist seither GEREGELT statt "volle Dichte" - ungeregelt lieferte die Schale
+das Sechsfache (2706 Cards an der Eiche).
+
+**Ast-Spitzen-Deckung: zwei echte Ursachen.** Der Kronenansatz-Filter stand auf
+25 % der Baumhoehe, die Tanne setzt ihre Aeste aber ab 12 % an - bei 5 von 22
+Aesten lag das aeussere Fuenftel KOMPLETT unter dem Filter. Er ist jetzt auf den
+tatsaechlichen `Branch Start` der Art gedeckelt. Und haengende Spitzen fielen
+unter den Filter: es zaehlt jetzt der ANSATZ des Astes (`anchor`) mit, nicht nur
+die Punkthoehe.
+
+**Groessere Baeume**, proportional skaliert (Hoehe, Astlaenge, Stammradius
+zusammen - Hoehe allein macht Stangen mit Minikrone): Eiche 9.3 m, Birke 11.0,
+Tanne 13.0, Weide 7.0. Alle unter dem 4300er-Deckel.
+
+Gemessene Spitzen-Deckung (Anteil der Aeste mit Laub im aeusseren Fuenftel):
+
+| | Aeste gedeckt | aeusseres Fuenftel |
+|---|---|---|
+| Eiche, Baum | 100 % | 100 % |
+| Weide | 100 % | 90 % |
+| Obstbaum | 100 % | 93 % |
+| Tanne | 86 % | 86 % |
+| Birke | 100 % | 72 % |
+
+**Die Metrik selbst musste zweimal korrigiert werden.** Erst mass sie den
+Abstand von der Astspitze zur naechsten Card-MITTE - viel zu streng: eine Card
+ist 0.85 m gross, ihre Mitte darf einen halben Meter weg sein und die Spitze
+trotzdem im Laub liegen. Bei 1.9 m Astlaenge kamen so 24 % heraus, obwohl das
+Polster genau auf der Spitze sass. Jetzt zaehlt DECKUNG: das aeussere Fuenftel
+gilt als gedeckt, wenn dort eine Card-Mitte naeher ist als eine halbe
+Cardlaenge.
+
+### Kugel-Kennwert relativ, Bbox-Kriterium ersetzt
+
+Die Bueschel-Schalen schieben jede Card um bis zu einen Kappenradius vom Ast
+weg, und zwar in ALLE Richtungen: die Krone gewinnt ringsum Breite, in der Hoehe
+aber nur oben. Der Obstbaum fiel dadurch von Kugel 1.35-1.47 auf 0.95-1.23,
+ohne dass an seiner Form etwas falsch war.
+
+Zwei Hypothesen dazu sind an der Messung gescheitert - beide klangen plausibel:
+der Kappen-Faktor 1.47 des Obstbaums (entkoppelt: 0.93-1.14 -> 0.95-1.23, fast
+nichts) und ein groesserer Kappen-Radius (1.3 und 1.6: 59-77 % -> 58-75 %, fast
+nichts). Der Radius waechst in alle Richtungen und verschiebt das Verhaeltnis
+deshalb kaum. Was wirkt, ist die Kronenbreite selbst.
+
+Die Schranke ist jetzt RELATIV: der Obstbaum muss die rundeste Art bleiben,
+hoechstens 65 % des Eichenwerts aus demselben Lauf. Eine neue Konstante haette
+bei der naechsten Bauform dasselbe Schicksal gehabt.
+
+**Und das Bbox-Kriterium ist raus.** "Bbox-Mitte == 0" stammt aus der Zeit vor
+der Stammbasis-Konvention und misst seither die falsche Sache - eine
+asymmetrische Krone kann ihre Bbox-Mitte gar nicht ueber dem Ursprung haben.
+Nachgemessen ueber drei Presets und drei Seeds:
+
+    Stammachse am Fuss   0.0000 m in ALLEN neun Faellen
+    Bbox-Exzentrik       0.08-0.39 m, streut mit dem Seed
+    im Verhaeltnis       3-13 % des Kronenradius
+
+Eine Verschiebung traefe den Stamm mit und waere ueber die Seeds konstant.
+Beides ist nicht der Fall. An seine Stelle tritt der BOUNDS-RADIUS, an dem das
+Culling haengt - geprueft nicht gegen eine Konstante, sondern gegen die
+Blender-Messung: Hoehe und Radius muessen denselben Skalenfaktor tragen.
+
 ### Vom Trichter ueber die Haube zur Kugel
 
 Zielbild ist der **Lollipop** der stilisierten Vektor-Illustration: kurzer