fix!: derive KeyDelegate nullability from the underlying field

[zantvoort]

Fixes #403

Problem

Metamodel.key() returns the argument unchanged when it already implements Key and wraps it in KeyDelegate otherwise. KeyDelegate.isNullable() returned delegate instanceof Key<?, ?> key && key.isNullable(), but by construction the delegate is never a Key, so every factory-built delegate reported non-nullable. That is precisely the check keyset pagination relies on to reject nullable cursor keys, so a wrapped nullable metamodel used as a pagination key silently skipped NULL rows across page boundaries: the exact failure mode the key() docs warn about.

Fix

KeyDelegate.isNullable() now derives the answer from the underlying metamodel. A delegate around a Key still answers through that key; any other delegate resolves the record field at the metamodel's path through a new MetamodelFactory.isNullable(Metamodel), bridged from storm-foundation via the reflective MetamodelHelper (the same pattern as root/of/flatten):

• a unique field applies its nullsDistinct setting, matching factory-built key metamodels;
• an inline record derives from its constituent fields, mirroring SimpleKeyMetamodel;
• a plain field reports its own nullability, because no unique constraint restricts its NULL values.

Nullability comes from the same RecordField.nullable() source the rest of the framework uses (null-marked-by-default contract; Kotlin resolves from the language type via the Kotlin reflection provider), so Java and Kotlin behave identically and no new dependency is introduced. The sealed-entity field-resolution block that appeared three times in MetamodelFactory is extracted into a shared fieldResolutionClass helper.

Breaking change

• scroll with a Metamodel.key()-wrapped nullable field now throws the descriptive PersistenceException instead of silently skipping NULL rows. This also applies to previously issued Scrollable tokens revalidated on their next scroll call. Callers that genuinely need such a key can implement Key/AbstractKeyMetamodel explicitly.
• A wrapped custom metamodel whose path does not resolve to a record field previously reported non-nullable; it now fails at validation time with a descriptive error.

findBy/getBy/getByRef do not consult isNullable() and are unaffected; non-nullable wrapped keys scroll exactly as before; KeyDelegate's record shape and equality semantics are unchanged.

Tests

• MetamodelTest: wrapped nullable and non-nullable scalar fields, the documented Metamodel.of factory route, nested paths resolving at the leaf field, and a nullable @FK column.
• RepositoryPreparedStatementIntegrationTest: scroll rejects a wrapped nullable key and still accepts a wrapped non-nullable key; testMetamodelKeyFactory tightened with assertSame for the inline-record case, which already carries the Key marker.
• KeyDelegateTest (storm-foundation, runs without storm-core): the test that asserted the always-false behavior is replaced by direct-key coverage of both nullability answers; derivation coverage lives in storm-core, where the factory is on the classpath.

Full reactor green (mvn test, all modules).

[codecov]

Codecov Report

❌ Patch coverage is 20.00000% with 36 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...va/st/orm/core/template/impl/MetamodelFactory.java	30.00%	12 Missing and 9 partials ⚠️
...undation/src/main/java/st/orm/MetamodelHelper.java	0.00%	14 Missing ⚠️
...orm-foundation/src/main/java/st/orm/Metamodel.java	0.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!