perf: measure an edit from the input to the frame that answers it

Drawing a point in a large drawing feels slow, and nothing currently
measures the thing the user actually waits for. `update` times the message
handler, `wires-build` and friends time the rebuild, but the span between
them — press to the frame that shows the new geometry — has no number.

Navigation already has exactly that plumbing: `record_nav_perf` stamps an
instant when the input arrives, `prepare` and `encode` pick it up, and
`nav-prepare` / `nav-render` report `input`, `build`, `prepare` and
`elapsed` from the original event.

`NavPerfOp::Edit` reuses it. `update` snapshots `geometry_epoch` before
dispatch and stamps the sample when it moved, so any message that changed
geometry — a drawn point, a grip commit, an undo — reports its full
latency rather than only the handler's share.

Diagnostic only: `record_nav_perf` sets a pending sample and nothing else,
so no LOD or settle behaviour changes.

Nothing is optimised here on purpose. Four call sites feed the snapper
along different branches, and picking one to instrument before knowing
which dominates is how the earlier rounds of this work were wasted.

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

src/scene/mod.rs

@@ -1432,6 +1432,10 @@ pub(crate) enum NavPerfOp {
     Pan,
     Zoom,
     Rotate,
+    /// A message that changed geometry. Reported through the same line as
+    /// navigation because the question is the same one: how long from the
+    /// input to the frame that answers it.
+    Edit,
 }
 
 impl NavPerfOp {
@@ -1440,6 +1444,7 @@ impl NavPerfOp {
             Self::Pan => "pan",
             Self::Zoom => "zoom",
             Self::Rotate => "rotate",
+            Self::Edit => "edit",
         }
     }
 }