Den Bereich fuer die Sortierung rekursiv suchen, nicht in zwei Spruengen

Der Ausdruck stieg mit zwei `left join` nach oben, weil der Baum als
hoechstens vierstufig galt. `unit_type` ist aber nur ein Etikett, und die
Organisation kann beliebig tief sein: bei Manner sind es sieben Ebenen.
Fuer 317 der 784 Personen lag der Bereich drei oder vier Spruenge ueber
der eigenen Einheit, der Ausdruck lieferte null, und diese 317 rutschten
beim Sortieren nach Bereich/Team nicht unter ihre Bereiche, sondern
allesamt in einen Block am Ende der Liste.

Der Aufstieg haelt beim ersten Bereich an, nimmt also den naechsten und
nicht den obersten -- sonst stuende bei fast allen "CEO", weil diese
Einheit ueber den sechs C-Level-Bereichen liegt und selbst einer ist.
Dieselbe Regel gilt in lib/reports-data.ts, das von der Wurzel absteigt
und den letzten Treffer nimmt; dort gab es den Fehler nicht.

Gegen den Bestand geprueft: vorher 467 von 784 mit Bereich, jetzt 784.

lib/employee-sort.ts

@@ -73,24 +73,38 @@ const einheitAusdruck = sql<string>`(
    limit 1)`;
 
 /**
- * Der Bereich darüber — die erste Ebene unter der Gesellschaft.
+ * Der Bereich darüber — die nächste Einheit über der Person, die als Bereich
+ * geführt wird.
  *
- * Ohne Rekursion: der Baum hat höchstens vier Ebenen (Gesellschaft, Bereich,
- * Abteilung, Team), also genügen zwei Sprünge nach oben. Sitzt jemand direkt
- * am Bereich, greift schon der erste Fall.
+ * Aufgestiegen wird rekursiv, nicht mit einer festen Zahl von Sprüngen. Hier
+ * standen zwei `left join`, weil der Baum als höchstens vierstufig galt
+ * (Gesellschaft, Bereich, Abteilung, Team) und zwei Sprünge damit reichten.
+ * `unit_type` ist aber nur ein Etikett, und die Organisation kann beliebig
+ * tief sein: bei Manner sind es sieben Ebenen, und für 317 der 784 Personen
+ * lag der Bereich drei oder vier Sprünge über der eigenen Einheit. Der
+ * Ausdruck lieferte null, und diese 317 rutschten beim Sortieren nicht unter
+ * ihre Bereiche, sondern allesamt in einen Block am Ende der Liste.
+ *
+ * Der Aufstieg hält beim ersten Bereich an, nimmt also den **nächsten** und
+ * nicht den obersten. Ohne das Anhalten stünde bei fast allen „CEO": diese
+ * Einheit liegt über den sechs C-Level-Bereichen und ist selbst einer. In den
+ * Berichten gilt dieselbe Regel — lib/reports-data.ts steigt von der Wurzel
+ * ab, dort gewinnt der letzte Treffer, und das ist derselbe Bereich.
  */
 const bereichAusdruck = sql<string>`(
-  select coalesce(
-           case when ou.unit_type = 'Bereich' then ou.name end,
-           case when e1.unit_type = 'Bereich' then e1.name end,
-           case when e2.unit_type = 'Bereich' then e2.name end)
-    from position_assignments pa
-    join om_positions p on p.id = pa.position_id
-    join org_units ou on ou.id = p.org_unit_id
-    left join org_units e1 on e1.id = ou.parent_id
-    left join org_units e2 on e2.id = e1.parent_id
-   where pa.employee_id = employees.id and pa.valid_to is null
-   limit 1)`;
+  with recursive kette as (
+    select ou.id, ou.name, ou.unit_type, ou.parent_id, 0 as tiefe
+      from position_assignments pa
+      join om_positions p on p.id = pa.position_id
+      join org_units ou on ou.id = p.org_unit_id
+     where pa.employee_id = employees.id and pa.valid_to is null
+    union all
+    select o.id, o.name, o.unit_type, o.parent_id, k.tiefe + 1
+      from kette k
+      join org_units o on o.id = k.parent_id
+     where k.unit_type <> 'Bereich'
+  )
+  select name from kette where unit_type = 'Bereich' order by tiefe limit 1)`;
 
 const standortAusdruck = sql<string>`(select name from locations where id = employees.location_id)`;