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>

docs/sync.md

@@ -61,6 +61,9 @@ syncs everything else.
     falls back to the colour it derives locally, and one pushing `color` has the key
     ignored. The test is not "did a field leave" but "does either side end up
     showing something wrong".
+  - v5 (#5168): attachments became a sync entity — an upload route keyed by the
+    client's id, and `attachment`/`preview` deletes in push. Additive, so it is
+    the `attachment_sync` feature and the floor stays.
 - **Additive change** (a new field, a new capability) → add a `sync_features`
   name. Do **not** raise a minimum. Old clients keep working.
 - **Breaking change only** → raise `MIN_CLIENT_PROTOCOL_VERSION` (or the client's
@@ -222,6 +225,14 @@ Body: `{ "changes": [ ... ] }` (max 1000 per batch). Each change:
 - **Labels:** `{entity: "label", op: "upsert"|"delete", id, edited_at, name,
   color}`. A per-owner name clash on a *different* id is rejected (fix locally
   and retry).
+- **Attachments and link previews** (`attachment_sync`): `{entity:
+  "attachment"|"preview", op: "delete", id, edited_at}`. Delete is the only op —
+  attachments are created by upload (below) and previews by the server. A removal
+  is **not** weighed under last-write-wins: there is no rival version of a
+  removed file, so it always applies. A row the caller can't see answers `noop`,
+  the same as one that never existed. Removals are explicit rather than "the
+  note's current attachment set" on purpose: push runs before pull, so a set
+  would delete an attachment another device added that this one has not seen.
 
 ### Conflict resolution — last-write-wins + history
 
@@ -251,18 +262,28 @@ had a newer edit and the client should adopt the server version on its next pull
 Metadata rides the delta feed (`id, url, mime, size, sha256`); the bytes move
 over the existing routes:
 
-- **Upload:** `POST /api/notes/<note_id>/attachments` (multipart, field `file`;
-  optional field `id` to keep a client-minted attachment id). Re-uploading an id
-  the note already has is an idempotent no-op. Server stores + hashes the bytes.
+- **Sync upload** (`attachment_sync`): `PUT /api/sync/attachments/<id>?note_id=
+  &filename=&sha256=`, body = the raw bytes, type in `Content-Type`. For a file
+  attached offline, sent after the note itself has landed. `201` stores it under
+  the client's id; `200 {"status": "exists"}` if the note already holds that id
+  (a retry); `400` if the bytes don't hash to `sha256`; `409` if the id belongs to
+  another note; `413` over `max_attachment_mb`; `404` for a note the caller
+  doesn't own. A `4xx` other than `404` is permanent — the client records it on
+  the attachment and stops retrying.
+- **Web upload:** `POST /api/notes/<note_id>/attachments` (multipart, field
+  `file`; optional field `id`, same idempotency).
 - **Download:** `GET /api/notes/<note_id>/attachments/<id>` (owner/shared scoped).
 - The client uses `sha256` to skip blobs it already holds and to verify
-  integrity after download. (Currently image mimes only; broadening to any file
-  is tracked separately.)
+  integrity after download. Any file type syncs.
+- Every insert or delete of an attachment or a link preview bumps its note's
+  `sync_revision` (triggers from 0015 and 0031), so a change to either reaches
+  other devices as the note.
 
 ## A sync cycle
 
 1. **Push** local changes since the last sync (batched). Apply the per-item
-   results (mark synced, adopt server version where `kept`).
+   results (mark synced, adopt server version where `kept`). Then upload the bytes
+   of attachments added offline whose notes have now landed.
 2. **Pull** from the stored `since` cursor until `has_more` is false. Upsert
    notes/labels into the local store; delete rows whose `purged_at` is set;
    download any attachment blobs referenced by a new/changed `sha256`.