He investigado el asunto a fondo y he abierto una PR para solucionarlo:
El problema reside en la exportación ICS, no en la zona horaria del servidor/contenedor. El evento exportado utiliza un TZID IANA, como Europe/Berlin, pero actualmente no incluye la definición correspondiente de VTIMEZONE que clientes como Outlook necesitan para interpretar de manera fiable las reglas de horario de verano.
La PR añade definiciones de VTIMEZONE a las descargas ICS con zona horaria, manteniendo al mismo tiempo los valores locales existentes de DTSTART/DTEND.
Para el ejemplo de este tema, la exportación ahora incluye las observancias de CET/CEST para Europe/Berlin, de modo que:
DTSTART;TZID=Europe/Berlin:20260811T170000
puede interpretarse con el correcto desplazamiento de verano UTC+2, en lugar de que Outlook recurra a UTC+1.
También he añadido cobertura para las reglas de horario de verano de Europa y Norteamérica, un caso de desplazamiento fijo y las transiciones estacionales más inusuales utilizadas por Africa/Casablanca.