Screenshots and video export switched the app's one CoordinateSystem to
1920x1080 for the whole capture, then switched it back. Anything the
editor did meanwhile used the wrong coordinates, and some of it could
leave the editor stuck in them. A side switch (Shift+F) during a video
export rebuilds the map, which replaces the CoordinateSystem; the export
then restored the old object and left the new one in screenshot mode,
so every stroke drawn afterwards was saved in the wrong place. A drag
while a capture ran was converted the same wrong way.

A capture now runs in a zone that supplies its own 1920x1080
coordinates (CoordinateSystem.runInCapture): inside it, and in every
Future and timer it starts, CoordinateSystem.instance is the capture's;
the editor, whose frames run outside it, keeps its own throughout. The
drawing layer's post-frame path rebuild holds on to the coordinates it
was built with, so in a capture it still sees the capture's.

With the editor never switched, the video dialog no longer flips it for
the export, and neither it nor the screenshot button needs to repair
the editor's drawing paths afterwards.

Tests: a capture keeps its coordinates across its awaits while the
editor re-lays itself out, and the editor's come back unchanged even
when the capture fails; the screenshot and video export tests now check
the editor never sees screenshot coordinates while they run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>