Send moved-card notices as Nextcloud notifications too

Each workflow now has a notify channel (mail, notification or both) next
to its recipient mode. Notifications go out per card through
OCP\Notification\IManager, so they show up in the bell and as push on the
mobile and desktop clients. Without the notifications app nothing is sent.
The one-off "workflow disabled" notice is sent as a notification as well.

Existing workflows keep mail (migration Version1004). Bumps to 35.3.0 so
the migration runs.

DEVELOPMENT.md

@@ -10,6 +10,7 @@ Informationen für Entwickler und Admins, die tiefer einsteigen. Die Nutzer-Doku
 - **Hintergrundjob:** [`RunWorkflowsJob`](lib/BackgroundJob/RunWorkflowsJob.php) ist ein einfacher `Job` ohne Intervall. Er läuft bei jedem Cron-Durchlauf und ruft [`WorkflowRunner`](lib/Service/WorkflowRunner.php) auf.
 - **Rechte-Kontext:** Der Runner arbeitet die Workflows nach Eigentümer gruppiert ab und setzt Deck jeweils auf diesen Nutzer, per `DeckIntegrationService::beginUserContext()`. Decks Berechtigungsprüfungen lesen nämlich nicht die Session, sondern eine pro Prozess festgelegte Nutzer-ID.
 - **E-Mail:** [`NotificationMailer`](lib/Service/NotificationMailer.php) verschickt über Nextclouds `IMailer`. Die Empfänger ermittelt `DeckIntegrationService::findNotificationRecipients()`, die Entscheidungsregel steckt in [`NotificationPolicy`](lib/Service/NotificationPolicy.php).
+- **Nextcloud-Benachrichtigungen:** [`NotificationPusher`](lib/Service/NotificationPusher.php) legt sie über `OCP\Notification\IManager` an, eine pro Karte, an dieselben Empfänger wie die Mail. Er speichert nur Rohwerte. Den deutschen Text baut [`Notifier`](lib/Notification/Notifier.php), registriert in `Application::register()`. Ist die App `notifications` für einen Empfänger nicht aktiv, wird nichts angelegt. Push aufs Handy übernimmt die Notifications-App selbst.
 - **Oberfläche:** [`src/PersonalSettings.vue`](src/PersonalSettings.vue) (Vue 3, `@nextcloud/vue` 9) spricht über [`src/api.js`](src/api.js) mit dem OCS-Controller [`WorkflowController`](lib/Controller/WorkflowController.php).
 
 ## Datenmodell
@@ -20,13 +21,15 @@ Die Tabelle `wfda_workflows` enthält eine Zeile pro Workflow:
 | --- | --- |
 | `board_id`, `source_stack_id`, `target_stack_id` | Deck-IDs |
 | `user_id` | Board-Eigentümer, in dessen Namen der Job läuft. Wird bei jedem Lauf aus Deck aktualisiert. |
-| `notify_mode` | `off`, `owner` oder `board` |
+| `notify_mode` | `off`, `owner` oder `board` (wer) |
+| `notify_channel` | `mail`, `notification` oder `both` (wie) |
 | `enabled`, `last_run` | aktiv? / letzter Lauf |
 
 Migrationen in [`lib/Migration/`](lib/Migration/):
 - `Version1000…` legt die Tabelle an.
 - `Version1001…` entfernt die früheren Filter-Spalten.
 - `Version1002…` und `Version1003…` ersetzen `notify_email` durch `notify_mode`. Ein gesetztes Häkchen wird dabei zu `owner`.
+- `Version1004…` fügt `notify_channel` hinzu. Bestehende Workflows bekommen `mail`.
 
 Migrationen laufen nur, wenn die App-Version steigt.
 
@@ -52,6 +55,7 @@ composer run test:unit   # PHPUnit
 Die Unit-Tests decken nur reine Logik ab, ohne Deck-Installation:
 - Fälligkeitsprüfung (`WorkflowRunner::isOverdue()`)
 - Empfängerregel (`NotificationPolicy::shouldNotify()`)
+- Benachrichtigungsweg (`NotificationPolicy::sendsMail()`/`sendsNotification()`)
 
 Die Deck-Anbindung lässt sich nur auf einer echten Nextcloud-Instanz mit Deck testen: