DefaultTransactionPrehandler finally block NPEs on early getState() failure, masking the original exception

**Problem**
In `DefaultTransactionPrehandler.prehandleApplicationTransactions()` (`platform-sdk/consensus-transaction-handling/src/main/java/org/hiero/consensus/transaction/handling/internal/DefaultTransactionPrehandler.java`), `latestImmutableState` starts `null` and the `finally` block unconditionally calls `latestImmutableState.close()`:

```java
ReservedSignedState latestImmutableState = null;
try {
latestImmutableState = signedStateNexus.getState(RESERVATION_LABEL);
while (latestImmutableState == null) {
latestImmutableState = signedStateNexus.getState(RESERVATION_LABEL);
}
...
} finally {
event.signalPrehandleCompletion();
latestImmutableState.close(); // NPE if getState() threw before assignment
preHandleTime.update(startTime, time.nanoTime());
}
```

If `signedStateNexus.getState(RESERVATION_LABEL)` throws before a non-null value is assigned, `latestImmutableState` is still `null` when `finally` runs. `close()` then throws an NPE, which masks/replaces the original exception (losing the root cause) and prevents `preHandleTime.update(...)` from running. `event.signalPrehandleCompletion()` executes just before the NPE, so the event is marked prehandle-complete even though no pre-handle work occurred.

**Trigger is internal** (`getState()` throwing due to a nexus/locking failure), not attacker-controlled input — not a security issue, but a real diagnostics/correctness bug (loses root cause, incorrect completion signal).

**Proposed fix**
- Null-guard the close in `finally`: `if (latestImmutableState != null) { latestImmutableState.close(); }`, per team discussion.

**Reference:** originally flagged as VLN-619 (hedera-security-issues#707) — confirmed not a security issue, but a real bug needing the null-guard fix.