Remove the Lombok dependency from the TCK module

Depends on https://github.com/hiero-ledger/hiero-sdk-java/issues/2890 https://github.com/hiero-ledger/hiero-sdk-java/issues/2891 and https://github.com/hiero-ledger/hiero-sdk-java/issues/2892

Lombok is used in exactly one module. `sdk`, `sdk-full`, `examples` and `example-android` contain
zero Lombok imports; `tck/src` contains 86 files that use it:

| Annotation combination | Files | Role |
|---|---|---|
| `@Getter @AllArgsConstructor @NoArgsConstructor` | 65 | JSON-RPC request parameters |
| `@Data` (partly with constructor annotations) | 21 | JSON-RPC response DTOs |
| `@NonNull` | 1 | single use |

Declared in `tck/build.gradle.kts:25,27`:

```kotlin
requiresStatic("lombok")
annotationProcessor("lombok")
```

The version is inherited from the `spring-boot-dependencies` BOM; there is no explicit constraint in
`hiero-dependency-versions/build.gradle.kts` and no `lombok.config` in the repository.

## Why remove it

The functional argument is weak on its own — Lombok works, and the TCK is a test harness rather than
a shipped artifact. The real argument is toolchain risk:

**Lombok is an annotation processor that hooks into internal `javac` APIs.** It is not a normal
library; it manipulates the compiler's AST through non-public interfaces. In practice this makes it
the most likely single point of failure when the project moves to a new JDK: each new major JDK
requires a Lombok release before this module compiles at all, and that release is outside our
control. For a project that wants to adopt new JDKs promptly, carrying that risk in a module that
delivers no production value is a poor trade.

Secondary benefits: one less annotation processor in the build, one less `requiresStatic` entry
papering over a non-modular jar, and — after [TCK 2/4] and [TCK 3/4] — roughly a thousand lines of
generated accessors and constructors that simply stop existing rather than being generated.

## Scope

By the time this issue is picked up, [TCK 2/4] should have eliminated all `@Data` usage and
[TCK 3/4] all `@NoArgsConstructor` usage. What remains:

- `@Getter` and `@AllArgsConstructor` on the parameter classes — removed either by converting those
classes to records (preferred; see the scope note in [TCK 3/4]) or by writing the accessors and
constructor explicitly.
- The single `lombok.NonNull` usage — replace with an explicit `Objects.requireNonNull` check or the
project's chosen nullability annotation.
- The build wiring itself.

If the parameter classes are *not* converted to records, this issue means trading generated code for
hand-written boilerplate, which is a legitimate reason to close it as "won't do" rather than to do it
badly. That decision should be made explicitly, not by default.

## Acceptance criteria

- [ ] No `lombok.*` import remains anywhere in the repository.
- [ ] `requiresStatic("lombok")` and `annotationProcessor("lombok")` are removed from
`tck/build.gradle.kts`.
- [ ] Lombok no longer appears on any compile or annotation-processor classpath
(`./gradlew :tck:dependencies` check).
- [ ] `tck` builds and the TCK suite is run against a network and passes.
- [ ] If any Lombok usage is deliberately kept, the reason is recorded here and this issue is closed
as "won't do" rather than left open.

## References

- `tck/build.gradle.kts:25,27`
- 86 affected files under `tck/src/main/java/com/hedera/hashgraph/tck/`