feat(domain): let an event pin its own time zone (#31)

Every write sampled ZoneId.systemDefault() and stamped it into
EVENT_TIMEZONE, so the column was real but only ever held the device's
zone: an event synced from elsewhere could be read in its zone, never
authored in one.

Give EventForm a nullable `timezone`, where null keeps meaning "the
device zone at save time" — so every existing call site behaves exactly
as before — and a non-null value pins the event to a zone it then tracks
across DST. toWriteTimes resolves the form's zone ahead of the device's;
toEditForm pins only when the stored zone differs from the device's, and
prefills such an event in its own zone so the form shows the wall-clock
the event actually means.

Two provider-contract bugs fall out of this:

- Editing the time of a foreign-zone event rewrote EVENT_TIMEZONE to the
  device's. The instants stayed right, so nothing looked wrong, but the
  event silently stopped tracking its zone and would drift an hour at the
  next DST boundary. Only the timesChanged gate spared title-only edits.
- A zone change with an untouched wall-clock is still a time change (the
  same 09:00 elsewhere is a different instant), so it now trips
  timesChanged and rewrites DTSTART instead of being dropped.

All-day events keep carrying no zone at all: they're date-anchored, and
the UTC midnights they normalise to are an anchor rather than a location.

TimeZoneCatalog is pure JVM so the search ranking and DST-aware offsets
stay plain JUnit tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/ARCHITECTURE.md

@@ -99,6 +99,30 @@ on-device — see plan 03):
   UTC, so zones ahead of UTC can't leak an extra occurrence.
 - All-day events are normalised to UTC midnights with an exclusive end.
 
+### Event time zones
+
+`EventForm.timezone` is the zone its wall-clock times mean, and **null means
+"the device zone at save time"** — not "no zone". The data layer resolves it in
+`toWriteTimes` and always stamps a concrete `EVENT_TIMEZONE`, so an ordinary
+event behaves exactly as it did before the field existed.
+
+- A non-null value **pins** the event: it keeps tracking that zone's offset
+  across DST no matter where the device is. `toEditForm` only pins when the
+  stored zone differs from the device's, so the optional Time-zone field stays
+  hidden on ordinary events and reveals itself (via `populatedFields`) on
+  foreign-zone ones.
+- A pinned event is prefilled **in its own zone**, so the form shows the
+  wall-clock the event means rather than the device's rendering of it.
+- A zone change counts as a **time change** even with the wall-clock untouched
+  (same 09:00 elsewhere is a different instant), so `buildEventUpdateValues`
+  includes it in `timesChanged` and rewrites `DTSTART`.
+- **All-day events never carry a zone.** They're date-anchored — the UTC
+  midnights above are an anchor, not a location — so the field is withheld from
+  the form entirely and `toWriteTimes` forces `"UTC"` regardless.
+
+Still device-zone-relative, and knowingly so: `RRULE`'s `UNTIL` rendering and
+`AllDayReminderEncoding`'s offset (see its KDoc).
+
 ## Save conflicts
 
 No locking. `openForEdit` keeps an `EditSnapshot` — the prefilled form