Refactor DiffMapHolder to separate UI snapshot state from background coordination

[johan456789]

Context

PR #70 (refactor-after-69-pending-read-state) added a minimal safety fix to confine diffMap cleanup mutations to Dispatchers.Main. That makes the current design safer, but it also highlights that DiffMapHolder is mixing two different responsibilities in the same state objects.

Problem

diffMap is Compose snapshot state used by the UI as an overlay for read/unread presentation. At the same time, background workflows also depend on and clear related state during flush, commit, and sync processing.

Even with Main-confined cleanup, this design still has drawbacks:

• UI state and background coordination state are coupled in the same holder.
• Future changes must remember that Compose snapshot state is thread-sensitive and should not be mutated directly from background paths.
• The class is harder to reason about because some state exists for rendering while some exists for durable sync and flush coordination.
• The current fix addresses thread confinement, but not the underlying separation-of-concerns issue.

Proposed Direction

Evaluate splitting responsibilities so that:

• Compose-facing UI overlay state remains UI-owned and Main-confined.
• Background coordination uses plain data structures or explicitly synchronized state that is not Compose snapshot state.
• DiffMapHolder exposes a cleaner boundary between optimistic UI state and persistence and sync bookkeeping.

A likely incremental path:

1. Keep the current Main-confined mutation helper as the boundary for UI state updates.
2. Introduce a separate non-Compose coordination structure for pending diff bookkeeping.
3. Derive or mirror the UI overlay state from that background state through a controlled boundary.

Why This Is A Good Idea

• Reduces the chance of future threading mistakes around Compose snapshot state.
• Makes DiffMapHolder easier to reason about and test.
• Improves separation of concerns between UI overlay behavior and sync and flush machinery.
• Builds on the boundary introduced in PR refactor(read-state): persist local/remote completion flags in pending ops #70 instead of leaving the current design as a long-term compromise.

Notes

This is a refactor follow-up, not a blocker for PR #70. The current Main-confined fix is an acceptable short-term solution.