calendar: resolve DTSTART against its own TZID

parseDT stamped a zoned or floating DTSTART as UTC while every window
around it is built in local time, so the two sides of every comparison
were in different frames. On a +03 box a 22:00 local event parsed as
22:00Z, past the end of the local day, and the whole evening dropped out
of the busy gate and the day plan. A 13:00 Moscow meeting read on a +04
box was recited at 17:00 next to its own printed 13:00.

DTSTART now resolves three ways: a Z suffix is UTC, a TZID is loaded from
the zone database, and a floating value is read in the caller's location.
tzdata is embedded because the deploy image carries none, and a silent
fallback to the box offset is the bug being fixed. FactKey and FactValue
stamp the owner's clock, so the key date the store range-scans is the
same day the plan asks for. FactSummary drops the time tail for callers
that print the hour themselves.
Found in review of #56 and #58.

cmd/mavweb/ambient_test.go

@@ -55,7 +55,10 @@ func meetingNotification() calendar.Notification {
 		Package: "com.google.android.gm",
 		Title:   "Планёрка",
 		Text:    "10:00-10:30",
-		Posted:  time.Date(2026, 8, 3, 9, 40, 0, 0, time.UTC),
+		// Local, like a phone relaying from the box's own timezone: the fact
+		// key and value are stamped on the owner's clock, so a UTC reading
+		// here would only be testing the offset of the test machine.
+		Posted: time.Date(2026, 8, 3, 9, 40, 0, 0, time.Local),
 	}
 }