There's two options:

Purge the duplicate data (kind of hinky and not that thorough in fixing problems, can cause other issues and may take too long, doesn't make sense for something like this)

Fix the base query that's used for the procedure/job to find and check confirmed vote (robust, solves the issue across the board especially if it's a query that's repeatedly used for a core process)

If the "glitch" (the proper term is "programming error" or "bug") was resolved through the second option, then it should be resolved for the "other hundred and fifty thousand" goalpost move as well.

Should also note back to fauxgnaws said

but the votes are all referring to one vote.

Voter ID here is likely a unique value in a column (maybe an incremented insert). You can't have 29 rows in the query pull with the same ID and the same date recorded, only one of those will get counted on any "Distinct" query of the Voter ID column. (e.g. SE\LECT DISTINCT VoterID, RecordedDate)

There's other ways to commit fraud instead of obviously bad UNION ALL statements.