fix: datetime handling in mealplans

[jonsch318]

Everybody hates timezones

This replaces datetime.Instant with time.Instant since the former is deprecated. But there are two fixes that I should explain in more detail

Lets start with an extreme example

Kitshn: Tokyo UTC+9
Tandoor: Berlin UTC+2

1. toStartOfDayString used to take the user timezone into account where i don't think it is quite clear if this is smart

Given a date like 2026-04-15T10:00:00+09:00 it would cut of the time and convert it to UTC i.e
send 2026-04-14T15:00:00Z in a round trip this would be converted back to UTC+9 again to 15.04.2026 again but in the server it 14.04.2026.

Although the time is "more" correct with the timezone since we strictly look at the date
We should always send back 2026-04-15T00:00:00+00:00 even for the example.

Maybe I am just thinking wrong

fun LocalDate.toStartOfDayString(): String {
//    return this.atStartOfDayIn(TimeZone.currentSystemDefault())
//        .toLocalDateTime(TimeZone.UTC)
//        .format(LocalDateTime.Formats.ISO) + "Z"
    return this.atTime(0,0,0)
        .toInstant(TimeZone.UTC)
        .toString()
}

2. This is more easy since it is just cleaner code. I don't know if the prior ones had bugs in some form, but the new one uses exactly the functions we need, so i am pretty sure about this one.