M10.7d: download attachment bytes into a content-addressed store (task 2107)

The client half of task 1942's server work. Metadata already rides the delta
feed; this fetches the payload so a synced image exists on the device.

Blobs are filed under their own sha256, so the same image attached to five
notes is stored once and re-downloading it is free — the dedupe the task asks
for falls out of content addressing rather than needing bookkeeping.

The hash is also the integrity check, applied on the way IN. Bytes that don't
hash to what the server advertised are refused rather than filed under a name
that lies about them — and because the blob then still counts as missing, the
next sync simply tries again.

SECURITY: the hash arrives in a server response and becomes a FILENAME, so it
is validated as 64 hex characters before touching the filesystem. Without
that, a hostile or buggy server could send "../../..." and steer a write
outside the blob directory. Tested.

A failed attachment never fails the sync. Notes are the primary data and have
already landed; aborting here would let one unreachable file block every
future sync. Counted, logged, surfaced in the UI as "they'll retry on the
next sync", and retried because the blob is still absent.

sha2 is pure Rust, so the Windows cross-compile lane pays nothing for it —
the constraint recorded in ci-requirements.md.

SPLIT, deliberately: this stores the bytes but does NOT yet render them in
the webview. That half needs a custom URI scheme or the asset protocol, whose
URL form differs by platform (Windows uses http://scheme.localhost/, others
scheme://localhost/) — and CI cannot verify webview rendering at all, being
headless with no webview. Guessing at it here would ship an unverifiable
change on the most fragile lane. Follow-up filed; synced images will show as
broken until it lands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SreJkbxB4gx8pPsu8QbLPi

frontend/src/desktop/bridge.ts

@@ -114,6 +114,9 @@ export interface PullSummary {
   labels_deleted: number;
   cursor: number;
   clobbered_dirty: number;
+  blobs_downloaded: number;
+  /** Attachments whose bytes didn't arrive. Retried next sync, never fatal. */
+  blobs_failed: number;
 }
 
 export interface SyncOutcome {

frontend/src/views/SyncView.vue

@@ -119,10 +119,17 @@ async function syncNow() {
     pending.value = await syncBridge.hasPending();
     const received = outcome.pull.notes_applied + outcome.pull.notes_deleted;
     const sent = outcome.push.created + outcome.push.applied;
-    lastResult.value =
-      received === 0 && sent === 0
-        ? "Already up to date."
-        : `Sent ${sent}, received ${received}.`;
+    const blobs = outcome.pull.blobs_downloaded;
+    const parts: string[] = [];
+    if (sent > 0) parts.push(`sent ${sent}`);
+    if (received > 0) parts.push(`received ${received}`);
+    if (blobs > 0) parts.push(`${blobs} attachment${blobs === 1 ? "" : "s"}`);
+    lastResult.value = parts.length ? `Synced — ${parts.join(", ")}.` : "Already up to date.";
+    // Attachments that didn't arrive are retried next sync, so this is a note, not
+    // an error — but saying nothing would leave a missing image unexplained.
+    if (outcome.pull.blobs_failed > 0) {
+      lastResult.value += ` ${outcome.pull.blobs_failed} attachment(s) didn't download — they'll retry on the next sync.`;
+    }
     // Rejections are the server refusing a specific change — surfaced, never
     // swallowed, because only the person can resolve them.
     if (outcome.push.rejected > 0) {