fix(frontend): downloadIcsFile rief nicht existierenden Endpoint auf — auf echten ics-feed umgestellt

- Vorher: apiClient.get('/calendar/{id}/ics-feed-public') — Endpoint
  existiert im Backend nie (live 404 bewiesen via curl; Reverse-Check aus
  der Frontend-Backend-Gegenüberstellung)
- Jetzt: nutzt getIcsFeedUrl() mit optionalem Token — derselbe Fluss wie
  IcsControls (Backend auto-generiert ics_token beim ersten Hit)
- Funktion war tot (kein Aufrufer), aber garantiert kaputt für jeden
  künftigen Nutzer des Download-Buttons

frontend/src/api/calendar.ts

@@ -263,9 +263,22 @@ export function getIcsFeedUrl(calendarId: string, token?: string | null): string
   return `${base}?token=${encodeURIComponent(token)}`;
 }
 
-/** Fetch ICS file as text (used by "Download .ics" button). */
-export async function downloadIcsFile(calendarId: string, calendarName: string): Promise<void> {
-  const response = await apiClient.get(`/calendar/${calendarId}/ics-feed-public`, {
+/** Fetch ICS file as text (used by "Download .ics" button).
+ *
+ * Runtime-bug fix: this used to call `/calendar/{id}/ics-feed-public` — an
+ * endpoint that never existed in the backend (404, proven via curl). The
+ * real endpoint is `/calendar/{id}/ics-feed` and requires the calendar's
+ * ics token (the backend auto-generates one on first hit when the user has
+ * a session with calendar:read — same flow the IcsControls component uses
+ * via getIcsFeedUrl).
+ */
+export async function downloadIcsFile(
+  calendarId: string,
+  calendarName: string,
+  token?: string | null,
+): Promise<void> {
+  const feedUrl = getIcsFeedUrl(calendarId, token ?? null);
+  const response = await apiClient.get(feedUrl, {
     responseType: 'text',
     transformResponse: [(d) => d],
   });