You can't; to figure out that your superclass has a non-noargs contructor, we'd need to run resolution first (figure out what you extend, and what the signatures are in that), but then we have to run multiple rounds on the symbol table, which is doable but extremely complicated. The vast majority of bugs in lombok exist in val and @Delegate code which does just that, and there are still corner cases (such as 'val' usage in an anonymous inner class used as a field initializer) where we've pretty much given up on ever supporting it properly.
What I'm trying to say is: We are willing to cross into the 'requires resolution' zone if the feature is truly worth it, but Here Be Dragons. We're not going to send stable core features like RequiredArgsConstructor that's worked without any hitch or caveat for years into that grey mist to address this issue.
Once we figure out a way to reliably apply or edit-in-place the symbol table we'll revisit.