[sharanggupta]

ConfigurationPropertyName.elementsOf already rejects a name with a leading or trailing dot (ConfigurationPropertyName.of(".foo") / of("foo.") both throw InvalidConfigurationPropertyNameException), but a repeated dot anywhere else in the name was silently accepted:

ConfigurationPropertyName.of("foo..bar").equals(ConfigurationPropertyName.of("foo.bar")); // true
ConfigurationPropertyName.isValid("foo..bar"); // true

The root cause is in ElementsParser.add: a repeated separator produces an empty element between the two dots, and add silently drops any empty element instead of flagging it, so "foo..bar" (or any number of repeated dots) parses as indistinguishable from "foo.bar".

This isn't just a strict-validation gap. The same ElementsParser backs the lenient adapt(...) path that SpringIterableConfigurationPropertySource uses to map raw property-source keys onto ConfigurationPropertyNames for relaxed binding. Two distinct raw keys that differ only by an accidental repeated separator — a typo in a .properties file, or any code that builds a key by concatenation — collapse onto the same name there too, and the source's Cache keeps whichever raw key happens to land first in an unordered HashSet, so one of two real, distinct configuration values is silently and non-deterministically dropped, with no exception or log output:

Map<String, Object> map = new LinkedHashMap<>();
map.put("my.app..name", "beta");
map.put("my.app...name", "gamma");
MutablePropertySources sources = new MutablePropertySources();
sources.addFirst(new MapPropertySource("app", map));
Binder binder = new Binder(ConfigurationPropertySources.from(sources));
binder.bind("my.app", Bindable.mapOf(String.class, Object.class)).get();
// => {name=gamma} -- "beta" has vanished, with no warning

(I ran this 5+ times with the insertion order swapped; the "survivor" is not insertion-order-dependent, it's purely HashSet iteration order.)

This PR closes the gap in the strict of()/isValid() API by extending the existing leading/trailing-dot check to also reject an internal repeated separator, consistent with how the name is already documented and tested to behave at the start/end of the string.

I want to be upfront that this does not, on its own, change the behavior of the lenient adapt(...) path, since that method is intentionally more permissive than of() (per its own Javadoc: "more lenient than of() in that it allows mixed case names... other invalid characters are stripped out during parsing"), and I didn't want to unilaterally change that shared, more-permissive code path without knowing which behavior the team would prefer there — reject the key outright during relaxed-binding iteration, pick a value deterministically instead of by hash order, or something else. Happy to follow up with whichever direction you'd prefer; the Binder reproduction above should still be useful context either way.

Added ConfigurationPropertyNameTests.ofNameShouldNotContainDoubleDot and extended isValidWhenNotValidShouldReturnFalse to cover this. Ran the full core:spring-boot properties/binder test packages locally (965 tests) — green, no regressions.