Stundenplan: Popup-Menü im Wochenraster statt Dropdown in der Tagesliste

Nutzer-Feedback: die Tagesliste-Buttons waren schon in Ordnung, das Problem
lag im Wochenraster darüber — ein Klick auf eine Stunden-Kachel führt dort
entweder in den Planungsviewer oder zur Einheitenplanung, ohne dass von
außen erkennbar wäre welches Ziel man bekommt. Tagesliste auf den
ursprünglichen Stand zurückgesetzt.

Neu: ein kleiner "⋮"-Button pro Kachel öffnet ein Popup-Menü mit vier
ausdrücklich benannten Zielen (Unterrichtsansicht/Planungsviewer/Sitzplan/
Planung). MenuFlyout statt ComboBox — dabei verstanden, dass ein
$parent[ItemsControl]-Vorfahrenpfad im Flyout nicht funktioniert, eine
normale {Binding} über die DataContext-Vererbung aber sehr wohl. Der
Direktklick springt jetzt außerdem "einheitlicher": bei einer Lesson
während der eigentlichen Unterrichtszeit direkt in den Unterrichtsmodus
statt in den Viewer.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

TODO.md

@@ -1918,18 +1918,35 @@ folgenden Punkte gehören direkt in `LehrerApp.Desktop`:
       den vollen Verlaufsplan-Editor öffnen müssen. Neue kleine
       `TeachingModeHomeworkViewModel : ObservableObject`, da `TeachingModeViewModel` selbst (wie
       `LessonViewerViewModel`) keine Bindable-Basisklasse hat.
-- [x] **4.5.24** Dropdown in der "Heute"-Tagesliste für Unterrichtsansicht/Sitzplan/Planung/
-      Planungsviewer (August 2026, Nutzer-Feedback): unklar, wie man aus dem Stundenplan zwischen
-      diesen vier Ansichten wechselt — bisher zwei Buttons mit teils vom Lesson-Status abhängiger
-      Doppelbedeutung ("Verlaufsplan ansehen"/"Zur Lerngruppe"). Ersetzt durch eine `ComboBox` pro
-      Zeile mit vier ausdrücklich benannten Zielen (`TodayLessonItem.DestinationOptions`,
-      `TimetableLessonDestination`-Enum) — Unterrichtsansicht/Planungsviewer nur wenn für den Slot
-      schon eine `Lesson` existiert, Sitzplan/Planung immer. Menü-Charakter: `SelectionChanged` in
-      `TimetableView.axaml.cs` setzt `SelectedItem` nach jeder Auswahl bewusst auf `null` zurück,
-      statt die Auswahl dauerhaft anzuzeigen. Drei der vier Ziele nutzen unverändert bestehende
-      `TimetableViewModel`-Commands (`StartTeachingModeCommand`/`OpenTodayLessonCommand`/
-      `OpenGroupCommand` — letzterer navigiert bereits zum Planung-Tab, Index 6); "Sitzplan" ist
-      neu (Sitzpläne-Tab, Index 2 — bisher nur indirekt über den Unterrichtsmodus erreichbar).
+- [x] **4.5.24** Popup-Menü im Wochenraster für Unterrichtsansicht/Sitzplan/Planung/Planungsviewer
+      (August 2026, Nutzer-Feedback, zweite Runde). Die erste Fassung hatte das Problem am
+      falschen Ort gelöst — ein Dropdown in der "Heute"-**Tagesliste** (unten angedockt), obwohl
+      die dortigen zwei Buttons laut Nutzer schon in Ordnung waren. Zurückgesetzt auf den
+      ursprünglichen Stand (zwei Buttons, `TodayLessonItem` ohne `DestinationOptions`). Das
+      eigentliche Problem lag im **Wochenraster darüber**: ein Klick auf eine Stunden-Kachel führt
+      dort in den Planungsviewer oder zur Einheitenplanung, je nachdem ob schon eine `Lesson`
+      existiert — von außen nicht erkennbar, welches Ziel man bekommt.
+      - **Popup-Menü:** kleiner "⋮"-Button pro Kachel (`Button.weekCellMenuTrigger`, oben rechts in
+        der Zelle überlagert) öffnet ein `MenuFlyout` mit vier ausdrücklich benannten Zielen.
+        Unterrichtsansicht/Planungsviewer nur wenn schon eine `Lesson` existiert, Sitzplan/Planung
+        immer (Planung ist ohnehin der Ort, an dem man eine Lesson für den Slot erst anlegt).
+        **Wichtiger XAML-Fallstrick, diesmal genauer verstanden:** ein `$parent[ItemsControl]`-
+        Vorfahrenpfad (wie beim normalen Zeilen-Button) funktioniert in einem `MenuFlyout` nicht,
+        weil dessen Popup nicht im normalen visuellen Baum hängt — **aber** eine normale
+        `{Binding}` ohne Vorfahrensuche funktioniert dort sehr wohl, weil Avalonia die
+        DataContext-**Vererbung** (kein Baum-Durchsuchen, nur der geerbte Wert) auch in Flyouts
+        korrekt weiterreicht. Trotzdem bewusst `MenuItem.Click` statt `Command`-Binding gewählt
+        (kein `WeekCellItem`-eigenes Command nötig): Handler in `TimetableView.axaml.cs` liest die
+        Zelle über `((MenuItem)sender).DataContext`, das Ziel über `Tag="{x:Static
+        vm:TimetableLessonDestination.…}"` — beides ohne jede Vorfahrensuche.
+      - **Einheitlicherer Direktklick:** `OpenWeekCellCommand` prüft jetzt zusätzlich, ob gerade
+        (heute, ±10 Minuten Toleranz) Unterrichtszeit der Stunde ist (neues
+        `TimetableViewModel.IsAroundTeachingTime`, `PeriodScheduleService`/"Stundenraster" als
+        Grundlage) — dann direkt in den Unterrichtsmodus statt in den Planungsviewer. Ohne Lesson
+        bleibt es beim Sprung zur Einheitenplanung. Das Popup-Menü bietet immer alle vier Ziele
+        explizit an, unabhängig von dieser Automatik. Nutzt bewusst `lesson.Date` statt
+        `WeekCellItem.Date` — letzteres ist nur bei Kopfzeilen gesetzt, nicht bei
+        Stunden-Kacheln (führte im ersten Testlauf zu einem Bug: die Automatik griff nie).
 
 **Wichtige Abweichung von der ursprünglichen Planung (5.2):** Vor der Umsetzung zeigte sich,
 dass 5.2 wie ursprünglich beschrieben eine zweite, parallele Fehlzeiten-Erfassung neben dem