reject leading colon in xsd:QName values in JavaQNameHolder

[aizu-m]

Found while comparing the two xsd:QName lexical paths.

loader.parse("<t:root xmlns:t='urn:t'>:abc</t:root>", null, null).validate()
returned true, with the value parsed as the unprefixed name "abc"

JavaQNameHolder.parse splits the value at the first colon, but the prefix NCName check is guarded by prefix.length() > 0, so a colon with an empty prefix slips through: :abc is outside the xsd:QName lexical space, yet it parses as abc bound to the default namespace. parse is the path the streaming Validator uses for xsd:QName and xsd:NOTATION values (via JavaQNameHolderEx / JavaNotationHolderEx.validateLexical) and the set path for XmlQName, so the bad value flows in from untrusted XML and validates clean. The rich parser path, XsTypeConverter.lexQName, already rejects a leading colon.

The fix applies the existing prefix check whenever a colon is present; isValidNCName rejects the empty prefix like any other invalid one. Values without a colon and valid prefixed values are unchanged. Regression test added.

This fix was found and prepared with AI assistance and reviewed by me before submitting.