Move an event by the days the hand moved it, not to the date dropped on

Dragging an event across the month grid wrote the date of the cell it
landed on into the event's stored start. Those are the same date only
while the event's time zone is the reader's.

An event kept in Asia/Tokyo at 15:00 is drawn to a reader in Phoenix at
23:00 the previous evening. Dropped on the 11th, it was written as the
11th in Tokyo -- which is the 10th on screen. It went where its own
calendar said rather than where the pointer did, one day short, every
time.

Moving by the difference between the two local days instead moves it
exactly as far as the hand did, and adding whole days to a stored wall
clock leaves the time of day alone without touching the zone -- so the
frame the rest of this path is careful about is still not crossed.

Found by giving the mock an event in a zone that is not the machine's.
Every other fixture used the machine's own, which cannot tell a correct
conversion from no conversion at all: the case that works is the one the
fixtures were all testing.

FEATURES.md

@@ -682,7 +682,11 @@ The editor is still there and still does everything a drag cannot.
   change that should go out with notice goes through the editor.
 - The new time is worked out **in the event's own frame** rather than through
   an instant: its stored wall clock is what moves, and its time zone is not
-  touched. Computing a new time from the reader's local hours and then
+  touched. A move in the month grid shifts it by the number of days the hand
+  moved it, rather than writing the date it was dropped on — those are the same
+  thing only while the event's zone is the reader's. An event kept in Tokyo and
+  read from Phoenix is drawn on the previous evening, so writing the dropped-on
+  date sent it a day earlier than the pointer went. Computing a new time from the reader's local hours and then
   re-expressing it in the event's zone converts twice, and the two do not
   cancel.