chore: Integrate JSpecify and @Nullable annotations for null-safety across the codebase

[sbuettner]

This issue tracks the adoption of JSpecify null-safety annotations (@nullable, @nonnull, @NullMarked, etc.) across the camunda/connectors codebase — including connector-sdk, connector-commons, connector-runtime, and the individual connector modules.

What should we do?

JSpecify is the emerging standard for Java null-safety annotations, with broad tooling support and a stable 1.0 release.

Goals

• Add org.jspecify:jspecify as a dependency to relevant modules
• Annotate public API surfaces in connector-sdk and connector-commons with @nullable / @nonnull where appropriate
• Add @NullMarked at the package level (via package-info.java) to opt modules into strict null checking by default
• Audit existing usages of @nullable from other annotation libraries (JSR-305, JetBrains) and migrate them to JSpecify equivalents
• Wire up NullAway as a compile-time checker via the Error Prone plugin to enforce nullability contracts in CI

Suggested Rollout

• Start with connector-runtime (core)
• Extend to connector-commons
• Roll out to individual connector modules incrementally
• Enable NullAway enforcement in CI once core modules are annotated

Why should we do it?

Currently, nullability contracts in the codebase are either undocumented or expressed inconsistently (e.g., via JSR-305 @Nullable/@nonnull, JetBrains annotations, or not at all). This makes it harder for:

• Developers to understand which parameters, return types, and fields may be null
• Static analysis tools (e.g., NullAway, IntelliJ, Error Prone) to catch null-related bugs at compile time
• Kotlin interop to correctly infer platform types

References

JSpecify website
JSpecify GitHub
NullAway
JSpecify user guide