You can work around this by putting traits in a different package and when testing mock that trait instead of the classes in your sealed jar. That could be construed as a security concern but you can argue against that quite easily.
You could seal a jar that imports all your unsealed code and not add any behavior there. That would give your customer the security he needs, but avoid you having to deal with the restrictions in tests or other implementations where you don't have this requirement.
I'm sure you're using dependencies that are unsealed, so you just make your own testable code a dependency of the sealed jar too.