Enforce non-null key in ValidatedKeyValue constructor

[zbnerd]

Issue #7577.

Summary

ValidatedKeyValue did not enforce the package-level @NullMarked contract on its key parameter.

As a result, KeyValue.of(String, T, Predicate<? super T>) could create a KeyValue instance with getKey() == null. The object remained usable for most operations (equals, hashCode, toString, etc.) but later failed with NullPointerException in compareTo.

This change adds the missing null check and aligns ValidatedKeyValue with ImmutableKeyValue, which already enforces non-null constructor arguments.

Change

ValidatedKeyValue(String key, T value, Predicate<? super T> validator) {
    this.key = Objects.requireNonNull(key, "key must not be null");
    this.value = String.valueOf(assertValue(value, validator));
}

Tests

Added regression tests covering:

• null key rejection in ValidatedKeyValue
• null key rejection through KeyValue.of(String, T, Predicate)
• null KeyName handling through the corresponding overload
• preservation of existing validator behavior for null values
• consistency between String and KeyName overloads

[zbnerd]

One thing that makes this look unintentional is the consistency of the other overloads.

If the validator overload were intended to allow null keys whenever the predicate accepts the value, I would expect all key-accepting overloads to behave similarly.

Instead:

• of(String, String) rejects null keys
• of(KeyName, String) rejects null keys
• of(KeyName, T, Predicate) rejects null keys
• only of(String, T, Predicate) silently stores a null key

So regardless of whether one views the predicate overload as a special case for value validation, the current behavior leaves a single entry point that handles null keys differently from every other overload.

That asymmetry is what made me think this is more likely a missing null check than an intentional API distinction.