Not in the built-in interfaces, no. Any input constraint like this adds more friction between the user and the interface, so whenever possible, we've been trying to reframe the annotation task in a way that doesn't require adding constraints and validation. Binary interfaces are nice in this way, because they're always "valid".
So if validation is a big concern for you or if you find that you receive a lot of invalid data, maybe you can find a way to present the task differently? Another question to consider: How important is an individual answer and annotating every single question vs. collecting as many annotations as possible in total?
If you're looking to train a model afterwards, the number of (correct) annotations is usually what matters. That's also why we generally encourage users and annotators to hit ignore if it takes them more than a few seconds to answer a binary task. Disrupting the "annotation flow" is often more harmful than skipping an example that doesn't have much weight overall. I think the same could easily apply for live validation, too. So if you have a clearly-defined validation logic, you can always filter out the "invalid" annotations afterwards.
That said, you could probably implement some type of validation in custom interfaces – e.g. via the native validation hints in form elements. It won't stop the user from submitting the answer, but it'd show a visual hint. And if you really want to disable the submission, you could even disable the buttons by adding the disabled attribute.
At the moment, Prodigy only fires the custom event prodigyanswer (when the user answers a question) – but we could also add one for prodigyrender and prodigyupdate. In the meantime, this thread has a nice example of a Greasemonkey script that uses the MutationObserver API.
Some of it may feel a little hacky, but as I said, this is all still very experimental, and you're one of the first to try out the new JS API before we make it "official".
No, but when we're considering implementing the custom JS across all interfaces, so you'll be able to also interact with non-HTML tasks via custom scripts.