refactor(sync): separate planning, execution, conflicts, metadata, and UI

[ClaudiaFang]

Priority

P1 — maintainability and correctness

Problem

SyncManager and SyncStatusView currently coordinate multiple concerns: discovering state, deciding actions, executing provider operations, detecting conflicts, persisting metadata, and presenting UI.

This makes sync behavior difficult to reason about and encourages provider/UI concerns to leak into core decision logic.

Proposed boundaries

• SyncPlanner: derive an immutable sync plan from local, remote, policy, and metadata state.
• SyncExecutor: execute push, pull, move, and delete operations.
• ConflictDetector: produce explicit conflict models.
• SyncMetadataStore: own metadata schema, migration, rename tracking, and persistence.
• ProviderCapabilities: describe batch, move, binary, symlink, and locking behavior.
• SyncStatusView: presentation and user interaction only.

Plan

• Document current responsibilities and dependency graph.
• Introduce data contracts for inputs, plans, results, and failures.
• Extract pure planning logic first and add table-driven tests.
• Extract provider capability decisions from UI code.
• Move metadata reads/writes behind a dedicated store.
• Keep confirmation and conflict UI behind interaction interfaces.
• Remove direct provider mutation from presentation components.

Acceptance criteria

• Sync planning can run as a pure unit test without DOM or provider mocks.
• UI renders plans/results but does not decide remote operations.
• Provider-specific behavior is represented through explicit capabilities.
• Existing push, pull, batch, move, delete, and conflict tests remain green.
• The refactor can be delivered incrementally without a behavior rewrite.