feat: null-marked models by default, aligning nullability with JSpecify

[zantvoort]

Implements #254 and #256: Storm's nullability contract is now fully aligned with JSpecify, one deliberate step further — models are null-marked by default. Java record components behave exactly like Kotlin properties: non-null unless marked, with @Nullable as the marked case.

Contract

• Kotlin (unchanged): the language type is the contract, resolved from Kotlin metadata by the Kotlin reflection provider.
• Java: a record component or constructor parameter is non-null unless
  • explicitly @Nullable (JSpecify's type-use annotation, jakarta.annotation.Nullable, or javax.annotation.Nullable), or
  • inside a @NullUnmarked scope — resolved by walking constructor → class → enclosing classes → package → module, nearest marker wins.
• Explicit @Nonnull/@NonNull is honored (and restores strictness inside @NullUnmarked); @NullMarked is honored and now matches the default.
• JSpecify treats unmarked code as unspecified and asks static tools to be lenient; Storm is a runtime boundary and interprets unspecified as non-null, because a silent NULL in an assumed-non-null field is the worst failure mode. This is the stated deviation, and it buys exact Java/Kotlin symmetry.

Implementation

• st.orm.core.spi.Nullability centralizes resolution and is shared by the record-component path (DefaultORMReflectionImpl) and the constructor-parameter path (ObjectMapperFactory), closing the drift Complete JSpecify null-safety support: honor @NullMarked scope and align the constructor-parameter check #254 identified — nullable annotations are load-bearing for the first time. JSpecify remains reflectively resolved and optional at runtime; resolution runs only when cached mapping metadata is built, never per row.
• Kotlin-compiled classes are exempt from the Java default (guarded via kotlin.Metadata).
• The annotation processor's own nullability determination (the @UK nullable-field warning) mirrors the runtime contract, including the scope walk, JSpecify type-use positions, and JetBrains annotations covering Kotlin kapt stubs.
• Error hints teach the new vocabulary: annotate @Nullable (JSpecify or jakarta) or opt out with @NullUnmarked.

Breaking changes (release-note material)

1. Hydration: unannotated nullable fields in existing Java models fail with the descriptive non-nullable error until annotated @Nullable (or their scope marked @NullUnmarked).
2. Join generation — the silent one: a bare @FK City city flips from LEFT JOIN to INNER JOIN, filtering rows without the reference instead of fetching them with a null field. This matches Kotlin's existing behavior for non-null FKs. Nullable FK columns must be @Nullable @FK to keep the LEFT JOIN.

Documentation and skills

docs/ rewritten from the old "nullable by default, use @Nonnull" contract across 12 pages (prose and every Java example; ~70 redundant @Nonnull removed, @Nullable added where the Kotlin counterpart is nullable — including join-semantics-bearing cases). The site's AI skills (website/static/skills/) updated the same way, including the inverted FK guidance. versioned_docs/ snapshots untouched; skills deploy with the next site build.

Testing

• New @NullMarked/@NullUnmarked test package plus JSpecifyNullMarkedIntegrationTest covering the semantic square: marked-scope rejection, happy path, @Nullable opt-out, @NullUnmarked cancellation.
• Suite fallout resolved under a strict policy: intended-nullable test records annotated @Nullable; exactly one test assertion inverted (PlainPreparedStatementIntegrationTest.testSelectPetTypedWithLocalRecordAndEnumNullThrows, which existed to assert the old lenient default and now asserts the new contract). Test model Address.city gained @Nullable to match the schema, correctly restoring LEFT JOIN in the SQL assertions.
• Suites green: storm-core 2271, storm-kotlin 1627 (unchanged, confirming the Kotlin exemption), storm-java21 517 (no fallout; its models were already annotated).

Closes #254
Closes #256