rename_label writes its rename once, merge or not

The rename UPDATE appeared twice: once for a merge's survivor and once for a
plain rename. The branch now picks which row is renamed, and one UPDATE follows.

DRY pass #2, batch 2, F7 (#5372).

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

core/src/local/store.rs

@@ -1069,7 +1069,7 @@ pub fn rename_label(conn: &Connection, id: &str, name: &str) -> rusqlite::Result
         )
         .optional()?;
 
-    if let Some((other_id, other_created)) = clash {
+    let renamed = if let Some((other_id, other_created)) = clash {
         let mine_created: String =
             conn.query_row("SELECT created_at FROM labels WHERE id = ?1", [id], |r| {
                 r.get(0)
@@ -1085,20 +1085,18 @@ pub fn rename_label(conn: &Connection, id: &str, name: &str) -> rusqlite::Result
         // knows to mark every affected NOTE dirty before the delete cascades the
         // membership rows away, which is what makes the merge reach the server.
         merge_labels(conn, &doomed, &survivor)?;
-        // The survivor may still carry the old spelling — it is the one that keeps
-        // existing, so it is the one that has to end up named what was asked for.
-        conn.execute(
-            "UPDATE labels SET name = ?1, updated_at = ?2, dirty = 1 WHERE id = ?3",
-            params![name, now(), survivor],
-        )?;
-        return load_label(conn, &survivor);
-    }
+        survivor
+    } else {
+        id.to_string()
+    };
 
+    // A merge's survivor may still carry the old spelling — it is the one that keeps
+    // existing, so it is the one that has to end up named what was asked for.
     conn.execute(
         "UPDATE labels SET name = ?1, updated_at = ?2, dirty = 1 WHERE id = ?3",
-        params![name, now(), id],
+        params![name, now(), renamed],
     )?;
-    load_label(conn, id)
+    load_label(conn, &renamed)
 }
 
 pub fn set_label_color(conn: &Connection, id: &str, color: &str) -> rusqlite::Result<Label> {