[calendar] Fix sliced multi-day sub-events starting at 23:59 instead of next day 00:00

[ago1776]

Fixes #4206

Problem

With sliceMultiDayEvents: true, a multi-day event is split into per-day slices (1/n), (2/n), … Every slice after the first was displayed as starting at 23:59 instead of the next day's 00:00.

Cause

In defaultmodules/calendar/calendar.js, the slicing loop advances the day boundary with:

let midnight = eventStartDateMoment.clone().startOf("day").add(1, "day").endOf("day");
...
event.startDate = midnight.format("x");   // start of the NEXT slice

midnight is .endOf("day") (23:59:59.999) but is assigned as the following slice's startDate, so each subsequent slice starts at 23:59:59.999 of the previous day rather than 00:00 of its own day.

Fix

Use the start of the day for the next slice's start:

- event.startDate = midnight.format("x");
+ event.startDate = midnight.clone().startOf("day").format("x");

Test

Adds an e2e regression test (sliceMultiDayEvents sub-event start time) that reuses the existing slice mock with a 24h timeFormat and asserts that no sliced sub-event time cell contains 23:59. It fails on the previous behaviour and passes with the fix.

Note: I could not run the full Electron e2e suite locally (resource-constrained hardware running production services); the fix logic was verified with a standalone reproduction and the test follows the existing sliceMultiDayEvents patterns. Happy to adjust based on CI.

[ago1776]

Closing as a duplicate of #4208, which carries the same one-line fix plus a regression test I validated locally (electron e2e: passes with the fix, fails on 23:59 without it). Consolidating to keep a single PR for #4206 — sorry for the noise.

[KristjanESPERANTO]

Just a friendly hint: You could have adjusted this PR here. That would have caused less noise.