A designer delivers a mockup to a developer. That mockup is delivered as part of the story, but may or may not be considered actual acceptance criteria.
Are you saying that whether or not it is AC varies from time to time, or that there is disagreement about this between designer and developer? If the latter, this is the first thing to get clarified: you have to have a common understanding of this.
After all, the mock may not even look finished or behave correctly. So how can it be considered AC?
This smells a bit of legalistic word-chopping to me. If this is the argument you're using with the designer or with management, I wouldn't expect them to be at all convinced. Especially if the conversation happens after development, instead of when the mockup was presented. Developer & designer need to understand themselves as part of the same team, working together to make the best product, rather than against each other trying to "win" some point or other. Part of PM's job is to cultivate that teamwork.
Mockups can and should be accompanied by verbiage describing anything not on the mockup, that are intended as AC.
Because of the iterative nature of agile, AC should generally be understood as "minimum for acceptance", not "exactly how we want it", with the understanding that desired improvements can go into the backlog & be prioritized alongside everything else.
Regarding the concern in your comment above
My concern is that if [designer & developer] work together like this then a control that we estimated to be 2 points could be in fact an 8 point control depending on what the designer actually decides they want.
This again sounds like you're not nailing down agreement on scope at the beginning of the sprint. The designer, of course, has to understand what the scope is for this sprint. Emphasizing that the sprint is timeboxed may be helpful: most people understand that you can only get a finite amount of work done in a finite amount of time. You may also need to explain (and reiterate) the concept of scope creep and its risk to the project overall.
What does the accompanying story look like? Maybe taking the design mockup as AC is part of the problem. A well-written story should specify what the user (or other actor) should be able to do, not how it is done.
EG, if the story says "A user can enter text in 2 fields and choose options from 3 dropdowns", then any issues such as these
If they add scrolling, editable fields, tooltips, animations, responsive design etc after the fact then this could actually happen.
are very obvious scope creep & there should be no problem rejecting them.