[Follow-up #255] Investigate bidirectional CQRS dispatch for synced likes

[podclaude]

Context

Follow-up from PR #255: Like/Unlike System

Original Finding

Synced likes are written directly to the projections table rather than dispatched as CQRS commands. This means the Like aggregate state won't reflect synced likes, and SnapshotLike checkpoints (built from aggregate state) won't include synced-only likes.

Current trade-off is acceptable (documented in sync_controller.ex) but could trip up future developers if stream compaction or aggregate-dependent features are added.

Acceptance Criteria

• Evaluate whether synced likes should be dispatched as CQRS commands instead of direct projection writes
• Consider impact on event store growth vs aggregate state accuracy
• If switching to CQRS dispatch: ensure idempotence handles re-sync of already-liked feeds
• Update documentation if approach changes

[podclaude]

Closing as by-design. The sync model intentionally separates two paths:

• Live events (POST /likes, POST /subscriptions, etc.) → full CQRS pipeline (command → aggregate → event → projector)
• Sync (POST /sync) → direct projection write, a single state reconciliation between server and device data. No history, no individual events.

Writing synced data directly to projections is the established pattern for all data types (subscriptions, plays, playlists, likes). Changing likes alone would be inconsistent; changing everything would break the sync model's design. The aggregate state divergence is acceptable because snapshots serve to compact the event stream, and synced data is already persisted independently.