It could be an error copying your code and configuration, but your InterceptorMapping there are errors with the bean ref, it is on capital letter
"DefaultCountValidationInterceptor "
instead of
"defaultCountValidationInterceptor "
Apart from that, you should remove the blank spaces at the end of the bean ids and class attributes of beans declared.
I've been trying to reproduce your error on 1905 Hybris OOTB code, but I cannot reproduce it, I tried it with the AddressValidator (which implement ValidatorInteceptor as well), getting the message from the exception shown on the error alert on backoffice:
Link to Backoffice address validation error alert image
The problem could be if an exception different from InterceptorException is thrown, like a nullPointerException, are you sure of having the count attribute filled an being not null?
It could be obvius, but if any of the attributes on the baseStore is changed, and then saved, the validation interceptor will be runned. My advice is checking nulls before accessing the count attribute for not getting an error, like:
if (baseStoreModel.getCount() !=null && (baseStoreModel.getCount() < 0 || baseStoreModel.getCount() > 100))
Doing the condition on this way will avoid the null problem, because if you're having the count attribute set to null, the condition will exit as soon as the first condition is evaluated as false (baseStoreModel.getCount() != null).
Another way to avoid the null error is having a defaultValue on your *-items.xml definition, adding a:
<defaultvalue>Integer.valueOf(0)</defaultvalue>
@JagadeeshKumar, as @Zaheer Attar has said on his answer https://stackoverflow.com/a/62415830/3346298 (really good point), you could have your own ModelExceptionTranslation Handler. But I would check, before customising anything, what is the error, I mean, what is the exception recieved on the
de.hybris.platform.platformbackoffice.services.handlers.ModelSavingExceptionTranslationHandler
Use a debug point there to check the content of the exception, the cause and even finding out if your message from your validator is there.
Once you know the exception you could know the real reason of why the OOTB TranslationHandler is not working as expected.
Developing a new Handler could not solve the root reason of the error which could create adjacent problems in the next future.