Re-query after own writes and on return to foreground (#364) (#370)

Views now re-query after the app's own writes and whenever the app comes back to the foreground, instead of relying only on the provider's change notification.

On the reporter's Samsung (Android 12, "My Calendar") edits and deletes went through, but no view refreshed until a restart. Tapping today in the agenda, which starts a fresh query, showed the correct data, so the provider had the change and the notification never reached us.

- `CalendarRepositoryImpl`: every write goes through a `write { }` helper that triggers a re-query when it finishes, also when the write threw.
- New `CalendarRepository.refresh()`, called from `MainActivity.onStart()`.
- Change ticks use `DROP_OLDEST`, so a tick is never dropped while a subscriber holds the previous one.
- The instances query filters `Events.DELETED = 0`, for providers that soft-delete and keep the instances around.
- `docs/ARCHITECTURE.md`: the observer principle mentions the extra re-queries.

The issue reads like a save/delete bug, but the writes themselves work. The fix targets the refresh, which is what was broken. The agenda opening on the 1st of the month, also mentioned in the thread, is the existing focus behaviour and isn't changed here.

Closes #364

Co-authored-by: Jean-Luc Makiola <business@jeanlucmakiola.de>
Reviewed-on: https://codeberg.org/jlmakiola/calendula/pulls/370

docs/ARCHITECTURE.md

@@ -12,8 +12,10 @@ the package list (recurring writes, save conflicts, reminder delivery).
    straight back to it. Sync is DAVx5's / Google's / the system's job.
 2. **Observer-driven UI.** A `ContentObserver` on the provider triggers
    re-queries; every screen recomposes from fresh provider state. After a
-   write, nothing is patched by hand — the provider notifies, the views
-   refresh. This also covers external changes (sync) for free.
+   write, nothing is patched by hand — the views refresh from the provider.
+   This also covers external changes (sync) for free. Some providers don't
+   reliably notify (#364), so the repository also re-queries after each of
+   its own writes, and `MainActivity` does on every return to the foreground.
 3. **JVM-first testing.** Everything between the UI and the
    `ContentResolver` is shaped so it runs as a plain JUnit 5 test: pure
    domain logic, cursor-free mappers, a `FakeCalendarDataSource` for