I guess calmly evaluating my conclusions and approaching the problem with a third algorithm (I had already devised two and compared the answers) and then calmly asserting that my answer was in fact correct was the right move.
I do this sometimes. A strong developer would have a good mix of defending the design decisions made and the acceptance of the errors made. This test should bring this characteristic to the forefront.
You can get similar results without crossing that line by asking questions like "can this be made faster?" and "is this correct?", soliciting proofs of lower bounds on asymptotic complexity and loop invariants (respectively). But you shouldn't tell a candidate that their code is broken when it isn't. Interviewing is stressful and scary -- don't make it worse just because you can.
A mathematical proof on the lower bound? is that a common request and something I should prepare for in an interview?
"Ah, no wonder it didn't work!"
Then draw out an IDE around the code with a big [Compile] button.
Maybe even Clippy in the corner of the whiteboard. "It looks like you're trying to get a job..."