perf(sync): persist batch metadata transactionally

[ClaudiaFang]

Priority

P1 — consistency and mobile performance

Problem

Batch sync operations may update metadata and call saveSettings() after individual files. This causes write amplification and can leave partially persisted state when a batch fails midway.

On mobile filesystems, repeated settings writes also add avoidable latency.

Plan

• Introduce an in-memory metadata transaction for batch operations.
• Stage per-file SHA, path, rename, deletion, and status changes.
• Persist once after successful execution.
• Define an explicit partial-result model when remote operations only partially succeed.
• Make retries idempotent and avoid treating staged state as committed state.
• Ensure single-file operations continue to use a simple atomic path.
• Add instrumentation/tests for saveSettings() call counts.

Acceptance criteria

• Successful batch operations commit metadata once.
• Failed batches do not report uncommitted metadata as synchronized.
• Partial remote success is represented explicitly and can be retried safely.
• Restarting after failure does not lose track of uncertain files.
• Tests cover full success, early failure, mid-batch failure, retry, rename, and delete.