Fix 409 (Conflict) causes and handling

We used to have 409 responses when the client was not in sync with the server state. But with yjs we can now always apply updates as long as they belong to the same session. Still some users are reporting changes being lost while editing with > 10 people in text. 409 Responses are showing in their logs.

Sync requests

Sync requests can trigger 409 responses if the underlying files etag and mtime differ from the document records values.
This will happen if a file is saved through a different mechanism such as desktop client sync or restoring an old version.

Client side handling

The client will see 409 responses to sync requests and process them as normal responses. This is important so the sync mechnism continues working even if there has been a different update to the file.
The 409 will 'only' cause the editor to display the conflict screen with both options to pick from.
One problem with the current approach is that every sync request that responds with a 409 will include the complete local file. As the sync continues even on conflicts that is actually quite a bit of overhead.

Could they cause removal of content added by the client or another client?

Currently I don't see how.

Save requests

✅ TODO

• create follow up issue for smoother handling of expired sessions
• look into save requests

Start by tracing the sync request handling described in the issue, including client-side processing of 409 responses and the conflict screen, then inspect the still-unresolved save-request path. Reproduce or review the reported cases involving more than 10 editors and determine whether 409 handling causes unnecessary complete-local-file transfers or lost changes; done means the affected handling is understood and the save-request behavior is covered.