Kotlin Tooling Java To Kotlin

# Post-Conversion Verification Checklist

Use this checklist after converting each Java file to Kotlin.

## Compilation & Tests
- [ ] The `.kt` file compiles without errors
- [ ] All existing tests still pass
- [ ] No new compiler warnings introduced

## Semantic Correctness
- [ ] No new side-effects or behavioural changes
- [ ] All public API signatures preserved (method names, parameter types, return types)
- [ ] Exception behaviour unchanged (same exceptions thrown in same conditions)

## Annotations
- [ ] All annotations preserved from the original Java code
- [ ] Annotation site targets correct (`@field:`, `@get:`, `@set:`, `@param:`)
- [ ] No annotations accidentally dropped during conversion

## Imports & Package
- [ ] Package declaration matches original
- [ ] All imports carried forward (except Java types that shadow Kotlin builtins)
- [ ] No new imports added unnecessarily

## Documentation
- [ ] All Javadoc converted to KDoc format
- [ ] `{@code ...}` → backtick code in KDoc
- [ ] `{@link ...}` → `[...]` KDoc links
- [ ] `<p>` paragraph tags → blank lines
- [ ] `@param`, `@return`, `@throws` tags preserved
- [ ] Class-level and method-level documentation preserved

## Nullability & Mutability
- [ ] Non-null types used only where provably non-null
- [ ] Nullable types (`?`) used for all Java types that could be null
- [ ] `val` used for all immutable variables/properties
- [ ] `var` used only for mutable variables/properties

## Collections
- [ ] `MutableList`/`MutableSet`/`MutableMap` for Java's mutable collections
- [ ] `List`/`Set`/`Map` only where Java used immutable wrappers

## Kotlin Idioms
- [ ] Getters/setters replaced with Kotlin properties where appropriate
- [ ] String concatenation replaced with string templates where clearer
- [ ] Elvis operator used where appropriate
- [ ] `when` expression used instead of `switch`
- [ ] Smart casts used after `is` checks (no explicit casts)

## Framework-Specific (check applicable items)
- [ ] **Spring**: Classes that need proxying are `open`; `@Bean` methods are `open`
- [ ] **Lombok**: All Lombok annotations removed; replaced with Kotlin equivalents
- [ ] **Hibernate/JPA**: Entities are `open` (not data classes); no-arg constructor provided
- [ ] **Jackson**: `@field:` and `@get:` annotation site targets correct
- [ ] **RxJava**: Reactive types correctly mapped to Coroutines/Flow
- [ ] **Mockito**: `when` keyword escaped or replaced with MockK equivalent

## Git History
- [ ] File renamed via `git mv` (not delete + create)
- [ ] Rename commit separate from content change commit


# Conversion Methodology

You are a senior Kotlin engineer and Java-Kotlin JVM interop specialist. Your task is
to convert provided Java code into **idiomatic Kotlin**, preserving behaviour while
improving readability, safety and maintainability.

## The 4-Step Precognition Process

Before emitting any code, run through the provided Java input and perform these 4 steps
of thinking. After each step, output the code as you have it after that step's
transformation has been applied.

### Step 1: Faithful 1:1 Translation

Convert the Java code 1 to 1 into Kotlin, prioritising faithfulness to the original
Java semantics, to replicate the Java code's functionality and logic exactly.

**Rules:**
- Java classes that are implicitly open MUST be converted as Kotlin classes that are
  explicitly `open`, using the `open` keyword.
- To convert Java constructors that inject into fields, use the Kotlin primary
  constructor. Any further logic within the Java constructor can be replicated with the
  Kotlin secondary constructor.

### Step 2: Nullability & Mutability

Check that mutability and nullability are correctly expressed in your Kotlin conversion.
Only express types as non-null where you are sure that it can never be null, inferred
from the original Java. Use `val` instead of `var` where you see variables that are
never modified.

**Rules:**
- If you see a logical assertion that a value is not null (