JSpecify migration — Phase 1: switch-flip on modules already using JSpecify

[jflo]

Parent: #10440

Scope

These modules already declare compileOnly 'org.jspecify:jspecify' and have JSpecify annotations sprinkled in, but NullAway is not enforced. Turn it on, fix the resulting diagnostics, mirror the build-file pattern from #10370.

One PR per module:

• testutil
• ethereum/ethstats
• consensus/common
• ethereum/referencetests
• evm
• ethereum/core
• ethereum/eth
• ethereum/api

Recipe

For each module's build.gradle:

compileJava {
  options.errorprone {
    check('NullAway', net.ltgt.gradle.errorprone.CheckSeverity.ERROR)
    option('NullAway:AnnotatedPackages', 'org.hyperledger.besu.<module-package>')
  }
}

tasks.named('compileTestJava', JavaCompile).configure {
  options.errorprone {
    check('NullAway', net.ltgt.gradle.errorprone.CheckSeverity.OFF)
  }
}

dependencies {
  errorprone 'com.uber.nullaway:nullaway'
  // existing compileOnly 'org.jspecify:jspecify' stays
}

Then fix the violations surfaced by the compiler. See parent for the playbook.

Why first

These modules already opted into JSpecify, so the diff should be the smallest. They also exercise the largest API surfaces in the project (ethereum/api, ethereum/core, ethereum/eth) — finishing them early means later phases can rely on properly annotated returns from these dependencies.

Definition of done

• Each module's build.gradle carries the NullAway block.
• ./gradlew :<module>:compileJava passes.
• CI green on a full build.