Explicit terminal state classification and enhanced diagram generation

## Summary

States in a kfsm state machine are implicitly terminal when `subsequentStates.isEmpty()`. Making this classification explicit would unlock several improvements.

## Proposal

Add an explicit way to classify states as terminal vs in-progress, either via:
- A marker interface / sealed subtype (e.g. `State.Terminal`, `State.InProgress`)
- A property on `State` (e.g. `val isTerminal: Boolean get() = subsequentStates.isEmpty()`)

## Benefits

### 1. Enhanced Mermaid diagram generation

The `mermaid()` function in `StateMachineUtilities` currently does **not** render `State --> [*]` arrows for terminal states. Adding these would make terminal states visually distinct in generated diagrams:

```
stateDiagram-v2
[*] --> Initial
Initial --> Processing
Processing --> Complete
Complete --> [*]
```

### 2. Compile-time safety via sealed subtypes

If states are split into sealed subtypes, exhaustive `when` expressions can enforce that business logic only handles the right category. For example, a `resume()` function could accept `State.InProgress` and the compiler would reject terminal states at compile time.

### 3. AwaitableStateMachine integration

`AwaitableStateMachine` already accepts `settledStates: Set`. If states are explicitly tagged as terminal, the settled states set could be derived automatically rather than maintained by hand.

### 4. Build-time invariant validation

A test invariant that asserts "every state classified as Terminal has `subsequentStates.isEmpty()`" would catch misclassifications early.

## Context

This idea came from reviewing state naming conventions in a downstream project (bitty-city), where states follow:
- **In-progress**: present-participle verb phrases (e.g. `CheckingEligibility`, `AwaitingConfirmation`)
- **Terminal/outcome**: past-participle or adjectival forms (e.g. `Settled`, `Reversed`, `Sanctioned`)

Start by reading the State model, mermaid() in StateMachineUtilities, and AwaitableStateMachine. Compare the proposed marker subtype and property approaches, then determine how explicit terminal states, Mermaid arrows, settled-state derivation, and the invariant test should fit together. Done means the classification design is implemented consistently and covered by tests.

Written by the indexing model from the issue text.