fix(import): don't lose Fossify's contact birthdays and anniversaries (#225)

Found the actual cause. Fossify mirrors Contacts birthdays and
anniversaries with startTS == endTS (MainActivity), so its exporter's
dayCode(endTS + 12h) rounds back to the starting day and writes
DTEND == DTSTART. We read that literally: a yearly series with
DURATION:P0D, which the provider expands into no instances at all. The
import reported success and the events were nowhere — matching the
report exactly ("birthdays, memorials, dates").

An all-day event may no longer end at or before it starts, and an all-day
DURATION is floored at P1D. Verified against the released parser, which
returns days=0.0 for all three fixture events.

Do not generalise this into sniffing PRODID: the same exporter is correct
for UI-created events (endTS anchors at noon of the last day) and for
CalDAV rows, and Fossify's bundled holiday files are conformant while
naming Fossify in their PRODID. Both are kept as fixtures.

Also: existingUids counted DELETED rows, so re-importing after deleting
events skipped everything as duplicates.

Closes #225

app/src/test/java/de/jeanlucmakiola/calendula/domain/ics/IcsFossifyImportTest.kt

@@ -10,12 +10,15 @@ import org.junit.jupiter.api.Test
  * Every fixture is shaped as `IcsExporter.writeEvent` emits it — property order,
  * the `X-FOSSIFY-*` extensions and the `P0DT1H5M0S` duration spelling included.
  *
- * Note what is *not* asserted here: their all-day `DTEND` is RFC-correct.
- * `Event.endTS` anchors an all-day event at noon of its last day
+ * Their all-day `DTEND` is *usually* RFC-correct and must not be "corrected":
+ * `Event.endTS` anchors a UI-created all-day event at noon of its last day
  * (`EventActivity.getStartEndTimes`), or at the exclusive midnight for a
  * CalDAV-sourced one, and the exporter's `+ TWELVE_HOURS` rounds either to the
- * following midnight. Treating it as inclusive would push every imported all-day
- * event out by a day.
+ * following midnight. Shifting those by a day would corrupt them.
+ *
+ * The exception — and the whole of #225 — is events mirrored from Contacts.
+ * `MainActivity` builds those with `startTS = endTS = timestamp`, so `+ 12h`
+ * lands back on the starting day and they export zero length.
  */
 class IcsFossifyImportTest {
 
@@ -53,6 +56,30 @@ class IcsFossifyImportTest {
         assertThat(days(event)).isEqualTo(1)
     }
 
+    @Test
+    fun `contact-mirrored birthdays export zero length and must not vanish`() {
+        // The reported failure (#225). Fossify mirrors Contacts birthdays and
+        // anniversaries with startTS == endTS, so the exporter's +12h rounds
+        // back to the starting day: DTSTART == DTEND. Read literally these are
+        // yearly series of zero-length occurrences, which the provider expands
+        // into nothing at all — the birthdays import "successfully" and are
+        // then nowhere to be seen.
+        val text = checkNotNull(
+            javaClass.classLoader?.getResourceAsStream("ics/fossify-contact-birthdays.ics"),
+        ).use { it.readBytes().toString(Charsets.UTF_8) }
+
+        val result = parser.parse(text)
+
+        assertThat(result.events).hasSize(3)
+        result.events.forEach {
+            assertThat(it.isAllDay).isTrue()
+            assertThat(days(it)).isEqualTo(1)
+            assertThat(it.recurrenceRule).startsWith("FREQ=YEARLY")
+            // Their all-day reminder encoding: "on the day", not midnight UTC.
+            assertThat(it.semanticReminderMinutes()).containsExactly(0)
+        }
+    }
+
     @Test
     fun `a real Fossify holiday file imports unchanged`() {
         // Shipped inside Fossify Calendar (assets/holidays/AT/public.ics). Its

app/src/test/resources/ics/fossify-contact-birthdays.ics

@@ -0,0 +1,64 @@
+BEGIN:VCALENDAR
+PRODID:-//Fossify//NONSGML Event Calendar//EN
+VERSION:2.0
+BEGIN:VEVENT
+SUMMARY:Anna Schmidt
+UID:101
+X-FOSSIFY-CATEGORY-COLOR:-1155931
+CATEGORIES:Birthdays
+LAST-MODIFIED:20250615T150640Z
+TRANSP:TRANSPARENT
+DTSTART;VALUE=DATE:19900412
+DTEND;VALUE=DATE:19900412
+X-FOSSIFY-MISSING-YEAR:0
+DTSTAMP:20260819T120000Z
+CLASS:PUBLIC
+STATUS:CONFIRMED
+RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=4
+BEGIN:VALARM
+DESCRIPTION:Reminder
+ACTION:DISPLAY
+TRIGGER:P0DT9H0M0S
+END:VALARM
+END:VEVENT
+BEGIN:VEVENT
+SUMMARY:Opa
+UID:102
+X-FOSSIFY-CATEGORY-COLOR:-1155931
+CATEGORIES:Birthdays
+LAST-MODIFIED:20250615T150640Z
+TRANSP:TRANSPARENT
+DTSTART;VALUE=DATE:19700603
+DTEND;VALUE=DATE:19700603
+X-FOSSIFY-MISSING-YEAR:1
+DTSTAMP:20260819T120000Z
+CLASS:PUBLIC
+STATUS:CONFIRMED
+RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=6
+BEGIN:VALARM
+DESCRIPTION:Reminder
+ACTION:DISPLAY
+TRIGGER:P0DT9H0M0S
+END:VALARM
+END:VEVENT
+BEGIN:VEVENT
+SUMMARY:Hochzeitstag
+UID:103
+X-FOSSIFY-CATEGORY-COLOR:-1155931
+CATEGORIES:Anniversaries
+LAST-MODIFIED:20250615T150640Z
+TRANSP:TRANSPARENT
+DTSTART;VALUE=DATE:20050917
+DTEND;VALUE=DATE:20050917
+X-FOSSIFY-MISSING-YEAR:0
+DTSTAMP:20260819T120000Z
+CLASS:PUBLIC
+STATUS:CONFIRMED
+RRULE:FREQ=YEARLY;INTERVAL=1;BYMONTH=9
+BEGIN:VALARM
+DESCRIPTION:Reminder
+ACTION:DISPLAY
+TRIGGER:P0DT9H0M0S
+END:VALARM
+END:VEVENT
+END:VCALENDAR