[reka18]

Durable hardening: failing tests ahead of the fix checkpoints

Failing tests for #214 (defects from the platform-redesign review of durable; root causes and open questions are on the issue). Rows follow your ruled fix order. Each test asserts what any correct fix must produce, so it fails on main and moves into the checkpoint that fixes it.

Order	Defect	Test
Fencing	A stale Handle and the Handle that recovered after it both get acknowledged Fires; recovery yields a third state	TestRecover_TwoHandlesOnOneInstance_JournalMatchesAnAcknowledgedHistory
Fencing	A Fire whose Append failed stays in the live instance, so the next acknowledged Fire diverges from the journal	TestRunner_FireAfterFailedAppend_MatchesJournal
Concurrency	Fire during the "Tick from its own timer loop" pattern loses acknowledged steps (2+ CPUs)	TestRunner_FireDuringTimerLoop_LosesNoAcknowledgedSteps
Replay	WithEventData is dropped on recovery	TestRecover_FireWithEventData_MatchesLive
Replay	A result from a canceled turn is committed on recovery	TestService_ResultFromCanceledTurn_NotCommittedOnRecover
Effects	Effects from Start, timer transitions and service results never reach the handler (DeliverToActor has the same gap)	TestRunner_EffectDispatch_{Start_AppliesEntryEffect, TimerTransition_AppliesEffect, ServiceSettle_AppliesEffect}
Effects	A failed dispatch is compacted away by the next checkpoint	TestRunner_EffectDispatch_FailedThenCheckpointed_AppliedOnce
Timers	Start doesn't arm the initial state's timer	TestClock_StartInTimedState_ArmsTimer
Timers	A checkpointed timer that fires in the tail is missed on replay	TestTimerCheckpoint_FiredAfterCheckpoint_ByteIdentical
Timers	A timer armed by a service result is lost on replay	TestService_TimerArmedBySettle_ReplaysOnRecover
Step reuse	After a checkpoint compacts tick barriers, the next Fire reuses a recorded step and is dropped with a nil error	TestRecover_StepAfterTickCheckpoint_IsPersisted
Growth	Ticks before a timer is due append a record each	TestClock_TickWithNothingDue_AppendsNoRecord

timerNotifyMachine's timer edge now also emits notify. The existing test using it never ticks.

Decisions the tests leave open

1. Fencing: takeover on Recover or optimistic concurrency on the step (both pass). A Recover that refuses while a Handle is held would need a release API.
2. Append first-writer-wins: keep, or reject conflicting content for a recorded step.
3. Store without a dispatch set: keep the no-op, or refuse the configuration.
4. Recover while the effect handler is down: fail as today, or recover and redispatch later.
5. Effect ids repeat across instances (step#ordinal#kind): add the instance (needs a dispatched-set migration), or pass the instance to the handler.
6. Machine version on recovery: expose RejectMachineVersionMismatch to Recover, or make it strict.
7. Middleware on replay: skip it, or mark replayed steps.
8. A timer whose transition fails is consumed, with the error only in results[i].Err: re-arm, surface from Tick, or leave.
9. Checkpoints carry the full trace history (8 KB at step 50, 157 KB at 1000): bound it or not.
10. Handle concurrency: the timer-loop test assumes concurrent Fire/Tick is supported, per drainClock; the alternative is a documented single-goroutine contract.
11. Journaling event data needs a state API (fireConfig is unexported); refusing the option on a Handle also passes the test.

Evidence (local, this branch)

Check	Result
14 new tests	all FAIL on main, each for its stated defect
existing durable tests, -race	ok
golangci-lint v2.15.0 (GOTOOLCHAIN=go1.27.3), vet, gofmt	0 issues

Regressions vs baseline: none. API diff: none (tests only).

[reka18]

Superseded: each failing test moved into the PR in stack #239 that fixes it. The stack starts at #229.