Port akka-core#31753: Run DurableStateBehavior delete effect asynchronously like persist

[pjfanning]

Delete effects in DurableStateBehavior were applied synchronously — side effects (thenRun, thenReply) fired immediately without waiting for the store to confirm the delete. This broke command ordering: commands queued after a delete could be processed before the delete completed.

akka/akka-core#31753

part of #2730

Changes

• Running.scala: Added handleDelete in HandlingCommands that transitions to PersistingState (mirroring handlePersist). Added onDeleteSuccess/onDeleteFailed handlers to PersistingState. DeleteSuccess/DeleteFailure messages were previously Behaviors.unhandled.
• DurableStateStoreInteractions.scala: Removed onDeleteInitiated hook (unused telemetry stub). Annotated cmd parameter as @nowarn unused.
• DurableStateBehaviorReplySpec.scala: Renamed test suite; added "handle commands sequentially" test covering mixed increment + delete ordering.
• DurableStateBehaviorSpec.scala (new): Basic tests for persist, delete, and sequential command handling on DurableStateBehavior.

c ! IncrementWithConfirmation(probe.ref)
c ! IncrementWithConfirmation(probe.ref)
c ! DeleteWithConfirmation(probe.ref)
c ! GetValue(probe.ref)
// Previously: GetValue could resolve before DeleteWithConfirmation completed
// Now: guaranteed ordering — Done, Done, Done, State(0)
probe.expectMessage(Done)
probe.expectMessage(Done)
probe.expectMessage(Done)
probe.expectMessage(State(0))

[He-Pin]

SHOULD we remove this?

[pjfanning]

Can't any harm keeping it. It is from the Akka PR

[He-Pin]

lgtm