For your specific example, I would the following:

Render only the possible valid options in the form and…

If the invalid state is most likely to happen (for whatever reason), I’d check if the user can in fact do this operation in the context and avoid the constraint error altogether by deflecting the operation to another flow.

However, If it’s something a little unpredictable (or I don’t want to enforce through workflow), I’d just “let it crash” and then treat the specific constraint error when the exception happens by redirecting the user back to the form and showing a nice message explaining the reason (this can easily be achieved using changesets).

The whole point of just letting things crash is to avoid too much defensive programming when you have more unknowns in the workflow that can lead to bad software state. I’d argue that you could avoid the bad state altogether by controlling the program flow or letting it crash (if you don’t know exactly what or how to handle the state), but this always depends on other factors like the software architecture and the workflow.

If you are using SPA, you might want to do validations in Javascript to avoid hitting the server.
If you have a REST API that is consumed by an integration, you might want to validate the inputs before actually doing something to avoid heavy lifting.
If you only have a form posting to an endpoint that goes to a context and calls a changeset, it might be light enough to process all the validations and return to the user.

IMHO, the amount of “defensive programming” you’ll apply drastically depends on constraints other than the one you are working with at the moment.

It depends, but in general malicious user is still user, so this gives you to which bucket such errors should go.