**Make time log synchronization idempotent to prevent duplicates**

[Harshit4847]

Description

The current time log synchronization flow is not fully idempotent, which can result in duplicate records being created on the backend when a sync request succeeds but the response does not reach the client.

Problem

The Android client generates a deterministic session id and includes it in the payload. However, the backend CreateTimeLogRequest DTO does not currently contain an Id or client session identifier.

As a result, the client-generated ID is ignored and the backend generates a new ID for every request:

Id = Guid.NewGuid()

This creates a duplicate-record risk during retries.

Example scenario

Android session is PENDING
        ↓
Client sends session to API
        ↓
Backend saves the record successfully
        ↓
Response is lost due to network/server issue
        ↓
Client still considers the session PENDING
        ↓
Client retries synchronization
        ↓
Backend creates a NEW record
        ↓
Duplicate server records

Therefore, the synchronization operation is currently not idempotent.

The same concern also applies to the Desktop client because it currently does not provide a client-generated session identifier that the backend can use for duplicate detection.

Suggested solution

Introduce a client-generated identifier for each session, for example:

• Add ClientSessionId to CreateTimeLogRequest.
• Persist the same identifier across retries.
• Add a unique constraint/index on:

(DeviceId, ClientSessionId)

• Make the API handle duplicate requests using an upsert or ignore-on-conflict strategy.
• Return the accepted client session IDs in the API response so clients can reliably mark sessions as synchronized.

Expected behavior

If the same session is submitted multiple times, the backend should recognize it as the same logical session and not create multiple records.

Same ClientSessionId
        ↓
First request  → Create record
Second request → Return existing/accepted record
Third request  → Return existing/accepted record

This would make synchronization safely retryable and prevent duplicate time log records caused by network failures or lost API responses.