Self-repair inconsistent state between instance and data elements

### Description

The primary concern here is a rare case where a data element has been locked, but the instance is still in a step that allows changes to a form. This has been observed happening if PDF generation fails. Data elements are being updated and locked, but an error prevents the instance from moving on to the next process step.

If the user tries again, the situation is locked. Attempting to lock data elements that are locked will fail. I believe we can have some self-repairing logic here. If a data element is already locked, there is no need to update data element with a lock.

I'm somewhat worried that the first PUT is not an attempt to lock the data element, but to perform an actual update. In which case the lock must be removed first.

### Additional Information

_No response_

### Tasks

_No response_

### Acceptance Criterias

_No response_

No files or tests are named. Start by tracing the PUT and retry flow that updates and locks data elements, then compare it with the instance step transition after PDF generation fails; done means a retry safely reconciles the instance and element states without rejecting already-locked elements or skipping a required unlock.

Written by the indexing model from the issue text.