Drag an event to move it, and its edge to resize it

The calendar could only be edited through the editor, so moving a meeting
half an hour meant opening a dialog, changing two fields and saving. Every
other surface a finger or a pointer drives already answers to a drag.

In the day and week grids an event moves by dragging it and changes length
by dragging its bottom edge, snapping to fifteen minutes. In the month
grid it moves to another day and keeps the time it had, because a month
cell is a day and nothing finer -- changing the hour as well would answer
a question nobody asked.

It goes through the same path a menu edit takes. A recurring event is
asked which dates it means, and the answer runs through runScoped, so a
date the server will only change as part of a whole series offers that
rather than failing.

Three things do not offer a drag, and the reasons are checked in one place
so no grid has to remember all three: a read-only calendar, an event with
no calendar, and a birthday -- which is derived from a contact and has
nothing on the server to move. The reserved classes the swipe gesture was
told to keep out of are exactly the ones that are draggable here, which is
what that reservation was for.

Invitations are not sent. A drag is a scheduling gesture, and mailing
every guest on each nudge of a block is not what the hand was asking for;
a change that should go out with notice goes through the editor.

The new time is computed in the event's own frame rather than through an
instant. Working it out from the reader's local hours and then
re-expressing it in the event's zone converts twice, and the two do not
cancel: caught in the browser, where an event moved two hours the first
time it was dragged in the month grid and then sat still, because after
that its stored time and the reader's agreed. Parsing the stored string
into its parts and adding minutes to those touches no zone at all, and a
resize sends only a duration, so the question does not arise there either.

FEATURES.md

@@ -638,7 +638,25 @@ work:
 *This and future* is not offered: the server refuses an occurrence that belongs
 to such a change, and where it does, ihasmail says so and offers the series.
 
-Events are edited in the editor rather than dragged around the grid.
+**Events are dragged.** In the day and week grids an event moves by dragging
+it and changes length by dragging its bottom edge, both snapping to fifteen
+minutes; in the month grid it moves to another day and keeps the time it had.
+The editor is still there and still does everything a drag cannot.
+
+- **A recurring event asks which dates it means**, the same question the menu
+  asks, and goes through the same path — so a date the server will only change
+  as part of a whole series offers that rather than failing.
+- **Only where it can be saved.** A read-only calendar offers no drag, and
+  neither does a birthday: it is derived from a contact and there is nothing on
+  the server to move.
+- **Invitations are not sent.** A drag is a scheduling gesture, and mailing
+  every guest on each nudge of a block is not what the hand was asking for. A
+  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
+  re-expressing it in the event's zone converts twice, and the two do not
+  cancel.
 
 ---