perf: say which message caused an edit's latency

The first measurement showed four consecutive edits at ~192 ms each with
a handler cost of 0.55 ms. That is below the `update` line's 5 ms
threshold, so the log reports the latency but not what asked for it —
and whether a live command preview is bumping the geometry epoch on every
mouse move is exactly the question the numbers raise.

`nav-prepare` now carries the message label alongside the op.

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

src/scene/mod.rs

@@ -1452,6 +1452,10 @@ impl NavPerfOp {
 #[derive(Clone, Copy, Debug)]
 pub(in crate::scene) struct NavPerfSample {
     pub(in crate::scene) op: NavPerfOp,
+    /// Which message caused it. An edit whose handler runs in under a
+    /// millisecond never reaches the `update` line's threshold, so without this
+    /// the log shows the latency but not what asked for it.
+    pub(in crate::scene) cause: &'static str,
     pub(in crate::scene) space: &'static str,
     pub(in crate::scene) mode: &'static str,
     pub(in crate::scene) started: iced::time::Instant,
@@ -2880,6 +2884,15 @@ impl Scene {
     }
 
     pub(crate) fn record_nav_perf(&self, op: NavPerfOp, started: iced::time::Instant) {
+        self.record_nav_perf_caused(op, "-", started);
+    }
+
+    pub(crate) fn record_nav_perf_caused(
+        &self,
+        op: NavPerfOp,
+        cause: &'static str,
+        started: iced::time::Instant,
+    ) {
         if !crate::perf::enabled() {
             return;
         }
@@ -2892,6 +2905,7 @@ impl Scene {
         };
         self.nav_perf_pending.set(Some(NavPerfSample {
             op,
+            cause,
             space,
             mode,
             started,