[MOOSE-407]: Block animation classes accumulate in "Additional CSS Class(es)" field

[spadilha]

What does this do/fix?

Fix animation classes accumulating in "Additional CSS Class(es)" field

When a block had animation settings configured, the animationControls HOC was appending animation classes to attributes.className and passing them back to BlockEdit. WordPress displays attributes.className in the "Additional CSS Class(es)" field, so any edit to that field would save the animation classes back into the attribute. On the next render, the HOC would append them again on top of what was already there, causing the classes to multiply on every keystroke.

The fix removes the className override from blockProps entirely. Animation classes for the saved output are already handled by the applyAnimationProps filter (blocks.getSaveContent.extraProps), so the HOC never needed to write them back into attributes.className in the first place. The HOC now only overrides style (for animation CSS custom properties) and leaves attributes.className untouched.

File changed: wp-content/themes/core/assets/js/editor/block-animations/index.js

QA

Links to relevant issues

• Link to Issue

Screenshots/video:

• Bug demo
• Link to Video

Pull request checklist

• I've added a changelog entry for these changes.
• I've linked to a relevant Jira issue.
• I've captured a screenshot or screencast of the changes and linked it above.