coherence-sync-field-ordering

A [Sync] setter that reads another synced field can run before that sibling is deserialized, so it combines the new value with last tick's data. On the authority both fields are set by your own code in order, hiding the race until two fields change in one packet.

Store Base and Bonus as raw [Sync] fields and compute Total in a getter, or recompute it in an [OnValueSynced] callback where all synced fields are guaranteed applied. Alternatively, have the authority compute and sync the derived value directly.

No, [OnValueSynced] fires only on remotes receiving the update, not on the authority that wrote the value. The authority must produce any derived reaction inline in its own write path.

No, setter execution follows binding-list order, which can change silently when you re-bake or reorder fields. Reordering tunes a race condition rather than fixing it; move cross-field logic to OnValueSynced, a getter, or LateUpdate instead.

A setter may store its own raw value and set a local dirty flag, since neither reads a sibling synced field. Any work that reads another synced field belongs in OnValueSynced, a getter, or a per-frame recompute.