Rename a state: update animation keyframe references and clear stale error (#3383)

[vchelaru]

Summary

Renaming a state did not reliably update animations that referenced it: the keyframe kept pointing at the old name, leaving a lingering Keyframe at time … references a state X which does not exist error (surfaced on the tree node and Errors tab after #3293/#3382). Fixes #3383.

The pre-fix symptom was deceptive: the error vanished the instant you renamed (the WPF binding nulled StateName, which trips neither error branch), so it looked fixed — but the keyframe was never actually rewritten, and re-selecting/reloading the element rebuilt the original reference and the error returned.

Root causes addressed

1. Plugin ordering — MainStateAnimationPlugin.HandleStateRename called RefreshViewModel() (which recomputes/broadcasts errors against the still-old keyframe names) before RenameManager rewrote the keyframes, and never recomputed afterward. Reordered: rewrite first, then RefreshViewModel recomputes + rebroadcasts.
2. WPF binding nulled the reference — rebuilding AvailableStates removed the old categorized name, so the keyframe ComboBox's two-way SelectedItem → StateName binding cleared StateName to null before the rewrite could match it. The post-rename name is now seeded into AvailableStates before the rewrite, so the binding accepts the rewritten value instead of nulling it.
3. Prefix via ToString() — the category prefix was built from StateSaveCategory.ToString() instead of .Name; switched to .Name to match the rest of the keyframe-name handling.

Persistence — single save path (no double write)

RenameManager.HandleRename(StateSave) rewrites the keyframe and does not save. Assigning keyframe.StateName raises PropertyChanged, which the plugin already persists through its centralized HandleDataChange (AnyChange) save — the same single path the sibling InstanceSave overload relies on. An explicit save here would write the .ganx twice per rename and trip external (and Gum's own) file watchers on a change that already settled. The ElementSave overload still saves explicitly because renaming the element file changes no keyframe property, so nothing triggers the implicit save there.

Tests

• AnimationStateRenameErrorTests: promoted HandleRename_OfCategorizedState_RewritesKeyframeAndClearsErrorOnRefresh to the Renaming a state doesn't update animation keyframe references (leaves a stale missing-state error) #3383 ordering regression guard (rewrite-then-refresh leaves no stale error) and removed the now-fixed RenameSequence_AsThePluginRunsIt_LeavesStaleError characterization.
• RenameManagerTests: the existing HandleRename_State_RenamesMatchingKeyframeStateName / …StateCategory… already pin the rewrite.

All 18 StateAnimationPlugin tests green; GumFull.sln builds with 0 errors.

Manual verification

The WPF ComboBox-binding half can't be unit-tested (needs a WPF host), so it's verified in the running tool: add a state (in a category), create an animation keyframe referencing it, rename the state → no missing-state error appears, the keyframe shows the new name, and it persists across reselect/reload.

Closes #3383

🤖 Generated with Claude Code

[vchelaru]

Closing as redundant. #3383 was already fixed at the root by #3389 (merged onto the same base this branch was cut from, mid-session): the keyframe state ComboBox was made IsEditable with a Text binding, eliminating the StateName null-coercion entirely, plus the HandleStateRename ordering fix. This PR re-introduced the AvailableStates-seeding workaround that #3389 deliberately reverted, so merging it would regress that design.