Describe the per-frame drag preview (#213)

Architecture.md

@@ -267,6 +267,17 @@ editor only catches up once the hand stops. The work runs **before** `app.render
 so what it writes is in the frame it waited for. The Vector art tab's drag uses it; while the
 gesture runs, its own copy of the rings is the truth and it never reads the model back.
 
+Every other drag goes through `editor/framePreview.ts` (#213): `FramePreview.request()` in the
+move handler, `cancel()` on release, one instance per gesture owner. The model is still written on
+every pointer move, only `state.preview()` waits for the frame. The Scene view (moving objects,
+polygon corners, tile strokes), the Texture tab (frames, slice edges, collision corners) and the
+graph canvases (nodes, groups, comments) use it. Measured with 120 extra objects in the scene and
+120 pointer moves 8 ms apart: 26, 34 and 29 ms per move before, 18, 18 and 17 after (the probe's
+own pause and round trip are in every number). The Texture tab had been paying twice: Pixi repeats the
+last pointer move a few milliseconds later to update hover, with the same native event, and
+each one ran a full preview. Inspector scrubbing and the gradient bar's colour stops still preview
+on every move.
+
 The toolbar's right edge shows the frame rate in edit and play mode alike; `__gm.fps()` exposes
 the same number to tests. It counts **drawn** frames over the time the renderer was **awake**:
 idle seconds are not slow seconds, so the readout answers "how smooth is it while it moves" and