Workspace: Scouts betreuen Creator wie das Management

Bisher hatten Scouts mit der Creator-Betreuung nichts zu tun -- keine
Profile, keine Betreuungsbereiche, keine Reports. Das aendert sich, mit
zwei bewusst gesetzten Grenzen.

GRENZE 1: nur zugeteilte Creator, keine Rollenregel.

Neue Tabelle betreuung (creator_id PRIMARY KEY -> betreuer_id). Ein
Creator hat genau EINE zustaendige Person, damit nie unklar ist, wer
gefragt ist. Das Management sieht ohnehin alle und braucht keinen
Eintrag. Wer nichts zugeteilt bekommt, sieht weiterhin nichts -- kein
Recht entsteht automatisch aus der Rolle.

Zugeteilt wird in "Personen & Zugaenge", direkt in der Personenzeile:
Betreuung ist eine Eigenschaft der Person, kein eigener Vorgang. Nur das
Management darf zuteilen -- koennte ein Scout sich selbst Creator geben,
haette er die Rechtevergabe in der Hand, die ihn begrenzen soll.
Zustaendig koennen nur aktive Scouts sein, kein Admin (der sieht alles)
und kein anderer Creator.

Bei der Uebergabe aus der Pipeline passiert die Zuteilung von selbst:
Wer jemanden gefunden hat, betreut ihn weiter. Genau darum geht es bei
"Creator-Onboarding starten". Umhaengen kann das Management jederzeit.

GRENZE 2: betreuen, nicht verwalten.

Profile, die fuenf Bereiche und Reports wie ein Manager. ABER:
- keine Zugangscodes, kein Sperren von Personen (personen.html bleibt
  admin-only, unveraendert)
- keine management-internen Felder. Der Scout bekommt admin_notiz,
  plan_start und naechster_review NICHT -- die Felder fehlen in der
  Antwort komplett, nicht nur in der Anzeige. Eine Notiz UEBER die
  Betreuung gehoert nicht in die Hand dessen, der betreut. Geprueft: Ein
  Scout, der admin_notiz mitschickt, aendert sie nicht.

Die Regel steht an EINER Stelle (betreuteIds / betreutWo / darfCreator
in workspace.js) und wird von sechs Modulen benutzt. Eine Rechteregel,
die an sechs Stellen steht, ist eine Rechteregel, die irgendwann an
fuenf Stellen stimmt.

Genau das ist beim Bauen auch passiert: workspace-calls.js hatte eine
wortgleiche Kopie der Kalender-Sichtbarkeit. Erweitert wurde nur der
Kalender -- Scouts sahen die Termine ihrer Creator, dieselben Termine
als Call aber nicht. Die Kopie ist jetzt weg, calls.js importiert die
Regel aus workspace-kalender.js.

Zwei Fehler, die die Aenderung selbst erzeugt haette, vorher gefunden:
- Report-Entscheidung: ein Scout haette eine Aufgabe angelegt, deren
  "Creator" er selbst ist -- die waere in jeder Auswertung falsch
  mitgelaufen. Zeigt jetzt auf einen seiner Creator.
- Bereichseintrag: derselbe Fehler. Ein Scout hat gar keinen eigenen
  Betreuungsbereich. Ein Eintrag ohne oder mit fremder Zuordnung landet
  beim ersten zugeteilten Creator, nie bei einem fremden. Geprueft:
  Mikas Bereich bleibt bei jedem Versuch unberuehrt.

server/workspace-personen.js

@@ -15,7 +15,7 @@
 
 import express from "express";
 import {
-  db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren,
+  db, protokolliere, echteIp, sitzungLesen, personAnlegen, codeNeu, personSperren, betreuungSetzen,
 } from "./workspace.js";
 
 export const personenRouter = express.Router();
@@ -54,9 +54,16 @@ personenRouter.get("/workspace/api/verwaltung/personen", (req, res) => {
                (SELECT COUNT(*) FROM sitzungen s WHERE s.person_id = p.id) AS sitzungen,
                (SELECT COUNT(*) FROM aufgaben a
                  WHERE (a.creator_id = p.id OR a.verantwortlich_id = p.id)
-                   AND a.status <> 'erledigt') AS offene_aufgaben
+                   AND a.status <> 'erledigt') AS offene_aufgaben,
+               b.betreuer_id,
+               (SELECT name FROM personen x WHERE x.id = b.betreuer_id) AS betreuer_name,
+               (SELECT COUNT(*) FROM betreuung y WHERE y.betreuer_id = p.id) AS betreut_anzahl
         FROM personen p
+        LEFT JOIN betreuung b ON b.creator_id = p.id
         ORDER BY p.aktiv DESC, p.rolle, p.name`).all(),
+      /* Wer ueberhaupt als zustaendig eingetragen werden kann. */
+      betreuer: db().prepare(
+        "SELECT id, name FROM personen WHERE rolle = 'scout' AND aktiv = 1 ORDER BY name").all(),
     });
   } catch (fehler) {
     console.error("[workspace] Personen lesen:", fehler?.message);
@@ -64,6 +71,45 @@ personenRouter.get("/workspace/api/verwaltung/personen", (req, res) => {
   }
 });
 
+/* ---------- Zuständigkeit ------------------------------------------------
+   Wer betreut welchen Creator. Nur das Management setzt das -- sonst
+   koennte sich ein Scout selbst Creator zuteilen und haette damit die
+   Rechtevergabe in der Hand, die ihn eigentlich begrenzen soll.         */
+
+personenRouter.put("/workspace/api/verwaltung/betreuung/:id", gleicheHerkunft, (req, res) => {
+  try {
+    const id = Number(req.params.id);
+    if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
+
+    const creator = db().prepare("SELECT id, rolle FROM personen WHERE id = ?").get(id);
+    if (!creator || creator.rolle !== "creator") {
+      return res.status(404).json({ fehler: "nicht_gefunden" });
+    }
+
+    const w = req.body?.betreuer_id;
+    if (w === null || w === "" || w === undefined) {
+      betreuungSetzen(id, null, { ...req.person, ip: echteIp(req) });
+      return res.json({ ok: true, betreuer_id: null });
+    }
+
+    const z = Number(w);
+    if (!Number.isInteger(z) || z < 1) return res.status(400).json({ fehler: "Ungültige Auswahl." });
+    const betreuer = db().prepare(
+      "SELECT id, name, rolle FROM personen WHERE id = ? AND aktiv = 1").get(z);
+    /* Nur Scouts. Das Management sieht ohnehin alle Creator und braucht
+       keinen Eintrag -- einer waere irrefuehrend. */
+    if (!betreuer || betreuer.rolle !== "scout") {
+      return res.status(400).json({ fehler: "Zuständig können nur aktive Scouts sein." });
+    }
+
+    betreuungSetzen(id, z, { ...req.person, ip: echteIp(req) });
+    res.json({ ok: true, betreuer_id: z, betreuer_name: betreuer.name });
+  } catch (fehler) {
+    console.error("[workspace] Betreuung setzen:", fehler?.message);
+    res.status(503).json({ fehler: "nicht_verfuegbar" });
+  }
+});
+
 /* ---------- Anlegen ----------------------------------------------------- */
 
 personenRouter.post("/workspace/api/verwaltung/personen", gleicheHerkunft, (req, res) => {