Make the phone work: touch reordering, reachable menus, and nothing lost offline

Four things that were built for a mouse on a desk and quietly did nothing
useful on a phone. The last one is the serious one.

**A note made offline lost everything written into it.** Its create
reached the server, the server named it something else, and every edit
still queued behind it went on addressing the name only that device ever
knew — 404, five retries, thrown away. The note arrived empty and
untitled, with nothing to say that anything had been lost. The database
was repointed at the new id all along; the queue was not. It is now, by
replacing the id across the whole queued payload rather than in a list of
named fields, because a list of fields is a list to forget to add to. The
same held for a notebook made offline and everything filed into it.

**The order of notes could not be changed on a phone**, because the list
went through the HTML5 drag API, which mobile browsers never fire from
touch. Pointer events instead, which mouse, pen and finger all produce. A
mouse still drags a row from anywhere; a finger drags from a grip,
because pressing the row has to go on scrolling and holding it has to go
on opening the menu. The row under the finger is found with
elementFromPoint — a finger raises no pointerover on anything it did not
press.

**"Move to..." opened off the side of the screen**, and could not be
opened at all without a hover. It is a tap now, unfolding in place where
there is no room beside the menu and flipping sides where there is. The
menu itself is placed by measuring rather than by assuming it is 220px
wide, its rows are tall enough to hit with a thumb, and Escape closes it.

**Installing said nothing when it could not be done.** The entry appeared
only when the browser had offered a prompt, so where installing was
impossible there was no button and no reason. It is always there now and
names the cause — most usefully that a browser will only install a site
served over HTTPS, which is also why the service worker would not have
registered, so one cause was showing up as two mysteries.

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

frontend/src/offlineStore.ts

@@ -225,6 +225,34 @@ export async function updateQueueEntry(queueId: number, patch: Partial<QueueEntr
   await reqToPromise(s.put({ ...entry, ...patch }));
 }
 
+/**
+ * Rewrites every queued reference to a temporary id.
+ *
+ * Something made offline carries an id this device invented. When its create
+ * finally reaches the server, the server names it something else — and every
+ * entry still waiting in the queue is addressed to the name nobody else knows.
+ *
+ * They used to be left as they were. The database was repointed and the queue
+ * was not, so the create arrived and then every edit behind it asked the server
+ * for `local_xxxx`, got a 404, retried five times and was thrown away: a note
+ * written and drawn on offline reached the server empty and untitled, with the
+ * work silently dropped.
+ *
+ * The replacement is a plain string match over the whole payload rather than a
+ * list of fields to look in. Ids are long random strings, so a false match is
+ * not a practical worry — and a list of fields is a list to forget to add to.
+ */
+export async function repointQueue(oldId: string, newId: string): Promise<void> {
+  if (!oldId || oldId === newId) return;
+  const s = await store("syncQueue", "readwrite");
+  const entries = await reqToPromise<QueueEntry[]>(s.getAll());
+  for (const entry of entries) {
+    const before = JSON.stringify(entry.data ?? {});
+    if (!before.includes(oldId)) continue;
+    await reqToPromise(s.put({ ...entry, data: JSON.parse(before.split(oldId).join(newId)) }));
+  }
+}
+
 export async function clearQueue(): Promise<void> {
   const s = await store("syncQueue", "readwrite");
   await reqToPromise(s.clear());