Improve sync reliability, diagnostics, and progress reporting

[imarquart]

Summary

• handle transient reMarkable API failures (429, 500, 502, 503, and transient HTML error pages) with retries instead of silently dropping items
• add user-facing sync diagnostics: richer notices, last-sync results in settings, and a persistent .sync-log.md
• add live sync progress in the status bar/modal, including cache hits, new downloads, re-downloads, skip reasons, and errors
• reuse existing synced markdown after a cache reset by reading remarkable_id and last_modified frontmatter so unchanged documents do not need to be re-downloaded
• remove the checked-in debug HTML response artifacts (response.txt, response2.txt)

Context

Thanks for publishing Slate.

I ran into an issue where new documents on reMarkable (in my case under 0 - Inbox) were not appearing in Obsidian, while Slate reported that everything was up to date. After digging into it, the main failure mode seemed to be that listing/metadata fetch failures were swallowed silently, so affected documents simply disappeared from the sync pass with no user-visible diagnostics.

This PR tries to stay close to the existing structure while making sync behavior more robust and much easier to understand when something goes wrong.

What this fixes

• documents no longer vanish quietly when metadata fetches hit 429, 500, 502, 503, or transient HTML error responses from the reMarkable backend
• sync now surfaces partial failures instead of only showing a generic success path
• long-running syncs expose meaningful live progress instead of only showing already syncing
• after a cache reset, unchanged documents that already exist in the vault can be recognized from existing markdown metadata and skipped instead of being fully re-downloaded
• sync runs now leave behind a user-readable log and last-run summary instead of requiring the developer console

Implementation notes

src/RemarkableClient.ts

• add retry/backoff for 429, 500, 502, and 503
• retry transient HTML error pages returned by the file endpoints before treating them as failures

src/SyncEngine.ts

• replace the eager listItems() walk with incremental listing logic that can reuse cached metadata
• extend syncState with visibleName, parent, and type so unchanged items can be reconstructed without re-fetching metadata every time
• record sync outcomes, failures, and progress snapshots
• write a rolling .sync-log.md into the sync folder
• rebuild cache state from existing synced markdown after a cache reset by reading frontmatter

src/SettingsTab.ts

• show the last sync results directly in settings
• add a button to open the sync log file

main.ts + src/SyncProgressModal.ts

• clicking the Slate status item during an active sync opens a live progress modal instead of triggering another sync request
• show status-bar progress counters during listing/syncing
• break progress down into cached hits, fetched-from-cloud items, new downloads, re-downloads, skip reasons, and recent errors

src/SyncLogger.ts

• centralize notice/log formatting for sync reports

Validation

• npx pnpm build
• local testing against a large existing vault sync
  • the sync state expanded from a tiny stale cache to hundreds of known items
  • the 0 - Inbox collection was detected during re-index
  • long-running syncs exposed progress and skip reasons instead of only the old generic status

Notes

• I kept this as one PR because the reliability work and the new diagnostics/progress reporting are closely related in practice.
• If you would prefer, I am happy to split this into smaller follow-up PRs.

Edit: Full disclosure, this was implemented with guided use of OpenCode (mix of Opus and Codex 5.4) (!)

[ComputelessComputer]

thx!