Changes Marked as Pending After User Restores Original Value (updateGroup)

Description:
When using an OData V4 model with two-way binding and an updateGroup, if a user changes a property and then manually sets it back to its original value, hasPendingChanges() still returns true. This results in unnecessary backend requests, even though there are no actual modifications left.

Steps to Reproduce:

1. Configure an OData V4 Binding with an updateGroup.
2. Bind (e.g., value of Input) to an OData V4 model property using two-way binding.
3. Change the input’s value from the original (e.g., "ABC") to a new value (e.g., "DEF").
4. Change the input’s value back to the original value ("ABC").
5. Call hasPendingChanges().

Expected Behavior:

• After restoring the original value, hasPendingChanges() should return false.
• No unnecessary backend requests should occur if no effective changes remain.

Actual Behavior:

• After restoring the original value, hasPendingChanges() returns true.
• Unnecessary backend requests are triggered when submitting the updateGroup changes.

Impact:

• Causes redundant server requests and additional load.
• Confuses users and developers, suggesting data is still modified.
• Complicates the process of batching changes.

Environment:

• UI5 version: 1.120.8
• OData V4 Backend: RAP with CDS

Additional Notes:

• Manual handling or resetting changes is required as a workaround.

Requested Fix:

• Improve the internal change tracking for updateGroup scenarios so that restoring a property to its original value is correctly recognized as no pending change.
• Ensure hasPendingChanges() accurately reflects actual modifications.