Frontend not showing changes in data model after service task

### Description of the bug

The GUI does not reflect updated data from the data model when the model is updated in a custom service task, unless the page is manually refreshed.
This issue occurs in a process that loops when an external API call fails.
**Process flow:**
- **Successful path:**
Form task → API service task → End
- **Failure path (loop):**
Form task → API service task → Error task (shows API error messages) →
Form task → API service task → Error task → …

A custom service task performs an API call and updates the data model with error messages when the API fails. These error messages are displayed in the subsequent error task (a form-filling task).
On the first API failure, the error task correctly displays the error messages from the data model.
On the second and subsequent API failures, the data model is correctly updated with new error messages, but the error task still displays the error messages from the previous iteration. The new values are not rendered in the GUI until the user manually refreshes the page.

This means the issue only manifests from the second time the process enters the error task, not the first.
The behavior is consistent across different approaches to updating or recreating the data model.

### Steps To Reproduce

1. Create an app with a process loop and a service task task1->custom service task -> task2 -> task 1
2. Update the data model in the sevice task
3. task2 displays the data changed in the service task
4. Navigate the loop and go to the service task again and change the data
5. observe that task2 still shows the first changes from the first iteration in the loop
6. Refresh the page and observe the latest changes

### Additional Information

**Atempted solutions**
- Updating data via `ServiceTaskContext.InstanceDataMutator.GetFormData` in the `IServiceTask`
- Using a dedicated data model for the error task, instantiated and populated in the service task
- Using a dedicated data model for the error task with `autoCreate`, populated in an `InstantiationProcessor` and deleted in `ProcessTaskEnd `so it is auto-created again on the next loop iteration

**Affected apps:**
[krt-3006a-1](https://altinn.studio/repos/krt/krt-3006a-1), [krt-1017a-1](https://altinn.studio/repos/krt/krt-1017a-1/src/branch/feature/feedback-task/)

Reproduce the loop in the affected apps krt-3006a-1 or krt-1017a-1, using a custom service task that updates error data across repeated API failures. Start by tracing how the frontend receives and renders updated data when returning to the error task. Done means each loop iteration displays the latest values without a manual page refresh.

Written by the indexing model from the issue text.