Describe the bug
Observed on the plh_kids_kw deployment, e.g. in this comment.
At a high level, the bug as observed is that when signing in with Google and choosing to load previously saved progress, the content does not seem to update in the case that the data being loaded is "behind" the current progress – in this case, when the user has completed more modules in the current session than they have in the data that is being loaded.

More technically, the issue is that when performing the user: import action to import dynamic data from a remote database user entry, the changes being applied from the imported data are just applied as updates to the apps dynamic data. This means that if updates have been made in the current session to a row that has no updates in the imported data, the current values will persist and will not be altered by the updates. This explains the behaviour as observed: when the user has currently made more progress through the modules than the data they import, the additional progress persists after import.

App version
code: 0.17.1
plh_kids_kw content: 1.2.26

To Reproduce
See this video demonstrating the behavior for the plh-kids-kw-uat1.web.app web preview. Progress has been made in the incognito on the left hand side. Progress is reset in the window on the right hand side, where the user is signed in, and a sync is performed. The window on the left then signs in and chooses to load saved progress (from the recently updated data from the other window). The additional progress persists.

https://drive.google.com/file/d/1gbddE8xTMLBX7mjjrH3d9zfmrzb8_UGE/view?usp=sharing

How
It is not completely clear whether this should be seen as a feature or a bug. It may be desirable to perform this kind of "merge" of the data rather than replacing any previously saved data. When loading previously saved data in the plh_kids_kw, a warning is shown that explicitly states that the current data will be lost. If that warning wasn't there, perhaps the current behaviour would be what the user expects?

However, it seems like for this use case, we probably do want to reset the user's data before applying the imported data. This could be achieved by resetting all local dynamic data before applying the updates from the imported data (we don't currently have a method to do so but could add).

Assuming its desirable, we could expose an option to the user: import action to toggle this behaviour, e.g. click | user: import: a_user_id | replace_data: true. Or, moving to our preferred action syntax, click | user: import | user_id: a_user_id, replace_data: true.

In fact, we may want to support other merge strategies in future, so could potentially anticipate that with the following syntax: click | user: import | user_id: a_user_id, merge_strategy: replace, or similar.