In gcal_calendar_monitor_init(), self->shared.lock is initialized with
g_rw_lock_init(). On Linux/glibc, GRWLock allocates memory for the
underlying pthread_rwlock_t (56 bytes).
Because g_rw_lock_clear() was never called in gcal_calendar_monitor_finalize(),
every finalized GcalCalendarMonitor leaked its lock resources, failing the
LeakSanitizer CI build when test_calendar_monitor_expand_recurrences was added.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/808>