Turn the argument on its head: why is it reasonable to ask someone who presumably knows better to waste time trying to solve a server problem on the client side? And why would it be unreasonable for a candidate to reject the premise and suggest a better solution?

(I often pose problems to candidates where challenging the given premise IS the point. You want people who will speak up)

I've spent perhaps a couple of decades designing and implementing various forms of distributed systems, and there are good reasons to avoid trying to hack your way out of trouble by requiring clients to behave a certain way. You will always have less control, it is almost never any easier than fixing the server side, and it doesn't actually address the root problem. You start at the end where the problem is instead of introducing hacks that run the risk of becoming long-lived.

You can always put something in front of a misbehaving backend that can compensate for the problem on the server side. In fact, this common enough that there exists a rich fauna of components that are used to address these kinds of issues. From more generic load balancers to more advanced application specific middleware. I've worked on perhaps half a dozen such systems and I've designed and implemented two of them from the ground up.

So yes, when people start trying to solve server problems by hacking the client, I tend to assume that they probably don't know what they are doing. And if they're not open to the possibility that they are wrong, why on earth would I waste my time working for them? Let alone try to convince them? Life is too short.