Fix _logId() collision via per-instance counter in SyncRepository

[Copilot]

_logId() relied solely on microsecondsSinceEpoch, making collisions possible when multiple log entries are created within the same microsecond (tight loops, tests, rapid sequential ops).

Changes

• SyncRepository: Added _logCounter field and updated _logId() to append it to the timestamp, mirroring the pattern already used by SyncManager._generateOpId()

// Before
String _logId() {
  final micros = DateTime.now().microsecondsSinceEpoch;
  return 'sync_log_$micros';
}

// After
int _logCounter = 0;

String _logId() {
  _logCounter += 1;
  return 'sync_log_${DateTime.now().microsecondsSinceEpoch}_$_logCounter';
}

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Copilot]

Pull request overview

This PR updates the bloc-like SyncRepository log ID generation to avoid collisions when multiple SyncLog entries are created within the same microsecond, aligning the approach with SyncManager’s timestamp + counter pattern.

Changes:

• Add a per-instance _logCounter and append it to _logId() to ensure unique SyncLog.id values during rapid log creation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Add a regression test covering the collision scenario this change fixes (multiple log entries created within the same microsecond). For example, create many logs in a tight loop (or stub DateTime) and assert all generated SyncLog.id values are unique and that markSyncing/markSynced updates the intended log rather than the first match.