Use a typed escalation fallback instead of fallbackTopic

TerdutTeam spec.escalation.fallback is now {type, address}, mirroring the
server's notification channel model. CRDs regenerated.

Claude-Session: https://claude.ai/code/session_016mBLURvJoMuUEr9cB2RpUN

examples/demo/01-server.yaml

@@ -41,6 +41,12 @@ spec:
   sweeper:
     staleAfter: 6h
     archiveAfter: 168h
+  # No ntfy anywhere in this demo can actually be reached; the URL only has to
+  # exist so the server has an "ntfy" notification provider and accepts the
+  # teams' escalation fallback (02, 03), which names one. A server with no
+  # provider refuses a fallback it could never deliver.
+  notify:
+    ntfyURL: "http://ntfy.invalid"
   # No oidc block: password login only, so there's nothing external to
   # register a redirect URI with before this demo can sign in.
   passwordLogin: true

examples/demo/02-team-platform.yaml

@@ -24,7 +24,9 @@ spec:
   # until that person exists -- run-demo.sh creates alice for exactly that.
   escalation:
     repeatCount: 2
-    fallbackTopic: platform-fallback
+    fallback:
+      type: ntfy
+      address: platform-fallback
     levels:
       - timeout: 5m
         targets:

examples/demo/03-team-payments.yaml

@@ -8,7 +8,9 @@ spec:
   displayName: Payments
   escalation:
     repeatCount: 1
-    fallbackTopic: payments-fallback
+    fallback:
+      type: ntfy
+      address: payments-fallback
     levels:
       - timeout: 5m
         targets: