tags: renaming onto an existing tag merges them, and the older row survives

The three surfaces did not agree on what renaming a tag onto a name another
one already holds should do, and none of the three answers was good.

I described this wrongly first time and the correction matters. The local
store does NOT silently create a duplicate: `idx_labels_name` is unique on
`lower(name)`, so the bare UPDATE in `rename_label` failed, and the user got
a raw SQLite "UNIQUE constraint failed" as their error message. The server
meanwhile answered 409 "a tag with that name already exists" — and only on
an EXACT match, because its constraint is on the raw name while every
client's index is on `lower(name)`.

That last part is the sharper bug. The server would happily hold "Groceries"
beside "groceries"; no synced client can store both. Creating that pair on
the web armed a pull that fails later, on a phone, in a path with no UI.

Operator's call: a rename onto an existing name means merge — typing an
existing tag's name onto this one says they are the same thing.

  * `store::rename_label` and the server's PATCH now implement one rule.
    THE OLDER ROW SURVIVES and takes the new spelling. Age rather than "the
    one that already held the name", so that renaming A→B and B→A land on
    the same survivor; otherwise the outcome depends on which way round
    someone typed it, and two devices tidying the same pair disagree about
    which id still exists. Ties go to the incumbent, so it stays
    deterministic.

  * The core reuses `merge_labels` rather than reimplementing the move. That
    is the only place that knows to mark every affected NOTE dirty before
    the delete cascades the membership rows away, which is what makes a
    merge reach the server at all.

  * The server's rename and its `/merge` route now share one `_merge_into`
    helper, for the same reason.

  * Both server lookups became case-INSENSITIVE, matching every client. The
    create path is included: it was the one actually minting the unstorable
    pair, so fixing only the rename would have left the door open.

  * The web asks before merging, naming both note counts. A merge cannot be
    undone by repeating it and is now reachable by a typo in a text field —
    the same reasoning as the delete confirmation in #2116. The confirmation
    lives in the shared store, so the desktop gets it too; the FFI does not
    ask, because that belongs to the surface with a person in front of it.

  * The web store detects the merge from the LIST, not the response: the
    survivor may be the row we asked to rename, so an unchanged id proves
    nothing.

Tests: three integration tests over a real database (both rename directions
land on the older row; a case-varied create returns the existing tag) and
two through the Android FFI, which is the binding the phone will use.

Also fixes a straggler from 8c7553d — the delete confirmation still said
"the label".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K3MMqUtzX1TJgA1oypvm1c

core/src/local/store.rs

@@ -820,7 +820,57 @@ pub fn create_label(conn: &Connection, name: &str) -> rusqlite::Result<Label> {
     load_label(conn, &id)
 }
 
+/// Rename a label. Renaming ONTO a name another label already holds MERGES the two.
+///
+/// It cannot simply be an UPDATE: `idx_labels_name` is unique on `lower(name)`, so
+/// the bare statement failed with a raw SQLite "UNIQUE constraint failed" that
+/// reached the user as database internals. Merging is the operator's call, and it
+/// is the reading that matches what a person means — typing an existing tag's name
+/// onto this one says "these are the same thing."
+///
+/// THE OLDER ROW SURVIVES, and takes the new spelling. Older rather than "the one
+/// that already held the name" because age is the property neither participant's
+/// role can change: rename A→B and rename B→A must land on the same survivor, or
+/// the result depends on which way round someone happened to type it. Ties (two
+/// labels minted in the same millisecond) go to the incumbent, so the outcome is
+/// still deterministic.
+///
+/// Matching is case-insensitive, agreeing with `find_or_create_label` — "Groceries"
+/// finds "groceries", and the survivor ends up spelled the way the caller asked.
 pub fn rename_label(conn: &Connection, id: &str, name: &str) -> rusqlite::Result<Label> {
+    let clash: Option<(String, String)> = conn
+        .query_row(
+            "SELECT id, created_at FROM labels WHERE lower(name) = lower(?1) AND id <> ?2",
+            params![name, id],
+            |r| Ok((r.get(0)?, r.get(1)?)),
+        )
+        .optional()?;
+
+    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)
+            })?;
+        // `created_at` is RFC3339 to the millisecond with a `Z`, so it is fixed-width
+        // and lexicographic order IS chronological order — no parsing needed.
+        let (survivor, doomed) = if other_created <= mine_created {
+            (other_id, id.to_string())
+        } else {
+            (id.to_string(), other_id)
+        };
+        // Reuse the merge rather than re-implement it: it is the only place that
+        // 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);
+    }
+
     conn.execute(
         "UPDATE labels SET name = ?1, updated_at = ?2, dirty = 1 WHERE id = ?3",
         params![name, now(), id],