feat(source-control): add push-selection and operation-state foundation

[ClaudiaFang]

Priority

P2 — foundation for a future Source Control UI, no user-visible change

Problem

Follow-up to #105. The sync domain model (SyncChange-equivalent via SyncPlanner/SyncExecutor) has no concept of per-file "included in the next push" selection or in-flight operation state — that's currently implicit in UI code. A future Source Control panel (VS Code-style staging UX) needs this as a pure data layer before any UI work starts.

Scope

• New src/logic/source-control/ module:
  • PushSelectionStore.ts — tracks which pending changes are included in the next push (includeForPush() / excludeFromPush()), separate from the underlying SyncChange/plan model. Avoid Stage/Unstage terminology — use "Ready to Push" framing.
  • OperationState.ts — tracks in-flight per-change operation state (idle/running/success/failed), separate from selection and from the change model itself.
• Pure, UI-independent, no provider/network access.
• Unit tests: include/exclude a change, multiple changes, refresh preserves selection, a change that disappears (e.g. reverted/synced) clears its selection.

Explicitly out of scope

• No new UI (Source Control panel, Ready-to-Push list, tree/list redesign) — that's a separate follow-up PR.
• No changes to existing SyncManager/SyncPlanner/SyncExecutor behavior.

Acceptance criteria

• PushSelectionStore and OperationState exist as pure, independently testable modules with no DOM/provider dependencies.
• Existing sync tests remain green.
• New unit tests cover the cases listed above.