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.js

@@ -222,6 +222,20 @@ export function db() {
       );
       CREATE INDEX IF NOT EXISTS idx_eintraege_bereich ON eintraege (bereich, creator_id);
 
+      /* Betreuung: wer kuemmert sich um welchen Creator.
+         Scouts betreuen Creator wie das Management, aber nur die ihnen
+         zugeteilten -- deshalb braucht es eine ausdrueckliche Zuordnung
+         und keine Rollenregel. Ein Creator hat genau eine zustaendige
+         Person (PRIMARY KEY), damit nie unklar ist, wer gefragt ist.
+         Das Management sieht ohnehin alle und braucht keinen Eintrag. */
+      CREATE TABLE IF NOT EXISTS betreuung (
+        creator_id  INTEGER PRIMARY KEY REFERENCES personen(id) ON DELETE CASCADE,
+        betreuer_id INTEGER NOT NULL REFERENCES personen(id) ON DELETE CASCADE,
+        seit        TEXT NOT NULL,
+        gesetzt_von INTEGER REFERENCES personen(id) ON DELETE SET NULL
+      );
+      CREATE INDEX IF NOT EXISTS idx_betreuung_betreuer ON betreuung (betreuer_id);
+
       /* Meeting-Protokoll zu einem Termin (Konzept, Seite 13).
          Bewusst eine eigene Tabelle statt neuer Spalten in termine: Es
          gibt hier keine Migrationen, und ein Protokoll gehoert ohnehin
@@ -407,11 +421,11 @@ const GESCHUETZT = {
   "/workspace/start.html": null,
   "/workspace/aufgaben.html": null,
   "/workspace/personen.html": ["admin"],
-  "/workspace/profil.html": ["admin", "creator"],
+  "/workspace/profil.html": ["admin", "creator", "scout"],
   "/workspace/kalender.html": null,
   "/workspace/dateien.html": null,
-  "/workspace/bereich.html": ["admin", "creator"],
-  "/workspace/report.html": ["admin", "creator"],
+  "/workspace/bereich.html": ["admin", "creator", "scout"],
+  "/workspace/report.html": ["admin", "creator", "scout"],
   "/workspace/scouting.html": ["admin", "scout"],
   "/workspace/calls.html": null,
 };
@@ -523,6 +537,66 @@ export function codeErzeugen(gruppen = 4, laenge = 4) {
    person_id, las sich der Eintrag so, als haette sie sich selbst angelegt.
    Wer betroffen ist, steht im Text. Ohne Akteur (Kommandozeile) bleibt
    das Feld leer. */
+/* =====================================================================
+   Betreuung — wer darf sich um welchen Creator kuemmern.
+
+   Scouts betreuen Creator wie das Management, aber nur die ihnen
+   zugeteilten. Diese Regel steht bewusst NUR hier: Sie wird von sechs
+   Modulen gebraucht (Profile, Bereiche, Reports, Aufgaben, Kalender,
+   Dateien), und eine Rechteregel, die an sechs Stellen steht, ist eine
+   Rechteregel, die irgendwann an fuenf Stellen stimmt.
+   ===================================================================== */
+
+/* Ids der Creator, die diese Person betreut. Fuer alle anderen Rollen
+   leer: Das Management sieht ohnehin alles, ein Creator sich selbst. */
+export function betreuteIds(person) {
+  if (!person || person.rolle !== "scout") return [];
+  try {
+    return db().prepare("SELECT creator_id FROM betreuung WHERE betreuer_id = ?")
+      .all(person.id).map((z) => z.creator_id);
+  } catch {
+    return [];   // im Zweifel nichts sehen, nie mehr
+  }
+}
+
+/* SQL-Baustein "diese Spalte gehoert zu einem meiner Creator".
+   Gibt null zurueck, wenn es nichts zu ergaenzen gibt -- eine leere
+   IN-Liste waere ungueltiges SQL. */
+export function betreutWo(person, spalte) {
+  const ids = betreuteIds(person);
+  if (!ids.length) return null;
+  return { wo: `${spalte} IN (${ids.map(() => "?").join(",")})`, werte: ids };
+}
+
+/* Darf diese Person den Bereich dieses Creators sehen und bearbeiten? */
+export function darfCreator(person, creatorId) {
+  if (!person || !creatorId) return false;
+  if (person.rolle === "admin") return true;
+  if (person.rolle === "creator") return person.id === Number(creatorId);
+  return betreuteIds(person).includes(Number(creatorId));
+}
+
+/* Zustaendige Person setzen oder entfernen (null loest die Zuordnung). */
+export function betreuungSetzen(creatorId, betreuerId, akteur = null) {
+  const d = db();
+  if (betreuerId === null) {
+    d.prepare("DELETE FROM betreuung WHERE creator_id = ?").run(creatorId);
+  } else {
+    d.prepare(`
+      INSERT INTO betreuung (creator_id, betreuer_id, seit, gesetzt_von)
+      VALUES (?,?,?,?)
+      ON CONFLICT(creator_id) DO UPDATE SET
+        betreuer_id = excluded.betreuer_id,
+        seit = excluded.seit,
+        gesetzt_von = excluded.gesetzt_von`).run(
+      creatorId, betreuerId, new Date().toISOString(), akteur?.id ?? null);
+  }
+  protokolliere("betreuung_gesetzt", {
+    personId: akteur?.id ?? null, rolle: akteur?.rolle ?? null, ip: akteur?.ip ?? null,
+    detail: `Creator #${creatorId} -> ${betreuerId === null ? "niemand" : "#" + betreuerId}`,
+  });
+}
+
 export function personAnlegen(name, rolle, akteur = null) {
   if (!ROLLEN.has(rolle)) throw new Error(`Unbekannte Rolle: ${rolle}`);
   const code = codeErzeugen();