attachments sync: attach offline, upload when linked, removals stick (#5168)

Desktop could not create an attachment at all, and a removed attachment or
dismissed preview came back on the next pull. Now:

- core: add_attachment keeps the bytes in the blob store and queues the row
  (schema v10: attachments.uploaded / upload_error). Push uploads it once its
  note has landed. A refusal that retrying won't fix (too large, id clash, hash
  mismatch) is recorded on the file and not re-sent every cycle; the editor
  shows it.
- core: removing a synced attachment or dismissing a preview leaves a tombstone
  in pending_deletes; push sends it as an `attachment`/`preview` delete, and a
  pull while it waits doesn't put the row back. A pull also keeps files still
  waiting to upload instead of replacing them wholesale.
- server: PUT /api/sync/attachments/<id> (raw body, sha256-checked, idempotent,
  size-capped) and child deletes in push, which apply regardless of LWW and
  answer noop for rows the caller can't see. One store_attachment helper for
  the upload route, the importer and sync. Protocol 5, feature attachment_sync;
  the client sends neither to a server without it.
- server: migration 0031 makes a link preview's insert/delete bump its note, so
  background-fetched previews and web dismissals reach linked devices.
- desktop: Attach and paste-image work offline (raw-bytes IPC command).
- SVG is served as a download by the desktop blob scheme too (as #1981 did for
  the web), and drawn as a file chip on both.
- autosync: drop the catch_unwind; release builds abort on panic, so it only
  ever worked in debug builds.

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

frontend/src/api/errors.test.ts

@@ -0,0 +1,28 @@
+import { describe, expect, it } from "vitest";
+
+import { errorMessage } from "./errors";
+
+describe("errorMessage", () => {
+  it("reads the REST client's error", () => {
+    expect(errorMessage({ error: "file is too large (max 25 MB)", status: 413 }, "x")).toBe(
+      "file is too large (max 25 MB)",
+    );
+  });
+
+  // A Tauri command rejects with its Rust error as a bare string.
+  it("reads a desktop command's string", () => {
+    expect(errorMessage("That note no longer exists.", "x")).toBe("That note no longer exists.");
+  });
+
+  it("reads a thrown Error", () => {
+    expect(errorMessage(new Error("Not running in the desktop app."), "x")).toBe(
+      "Not running in the desktop app.",
+    );
+  });
+
+  it("falls back when there is nothing to say", () => {
+    expect(errorMessage(undefined, "Could not upload file.")).toBe("Could not upload file.");
+    expect(errorMessage("  ", "fallback")).toBe("fallback");
+    expect(errorMessage({ status: 500 }, "fallback")).toBe("fallback");
+  });
+});

frontend/src/api/errors.ts

@@ -0,0 +1,16 @@
+// What went wrong, in words to show a person, from whichever layer failed.
+//
+// The two backends reject differently: the REST client with an `ApiError`
+// (`{ error, status }`), a Tauri command with the plain string its Rust `Err` held.
+// A catch that reads only `.error` turns every desktop failure into its generic
+// fallback — "Could not upload file." when the store said exactly why.
+
+export function errorMessage(e: unknown, fallback: string): string {
+  if (typeof e === "string" && e.trim()) return e;
+  if (e && typeof e === "object") {
+    const { error, message } = e as { error?: unknown; message?: unknown };
+    if (typeof error === "string" && error.trim()) return error;
+    if (typeof message === "string" && message.trim()) return message;
+  }
+  return fallback;
+}