[reka18]

What this change does

Timers survive recovery, and idle ticks stop growing the journal. Stacked on #235.

• Start arms the initial state's timers and carries them in the baseline. An instance started before this change keeps its initial timer unarmed.
• Recovery re-arms checkpointed timers before the tail replays. A held replay clock keeps that arming from consuming a recorded reading.
• RunService records the clock read that arms a timer, and replay arms it, in both Recover and StateAt.
• The Handle's timer table follows the scheduler: after a tick it keeps only what the scheduler still holds, and a chained timer takes the deadline the scheduler armed, after the transition's actions ran.
• A tick that fires nothing records nothing. This stays in durable, so state is untouched.
• Replay reads an older journal's idle tick Record as nothing fired, so a re-armed timer can't fire there. An older journal left a settle's clock read at the front of the next Record, so replay aligns on each Record: a step's own reads are the last ones in it. Two kinds of older journal can't be repaired, and can recover differently or fail Recover: an instance that continued after an older recovery missed a fired timer, and a checkpoint taken after a tick that followed a settle or whose clock moved mid-tick, which can hold a wrong timer table. No reader can tell these journals apart. An idle Tick doesn't touch the Store, so a stale owner finds out on its next real step, not on the idle tick.

StateAt also re-arms the baseline's timers, so a timer armed by Start or carried by a checkpoint fires in the replayed window.

Known and left open: a timer whose transition fails is consumed and reported only in its FireResult.Err, not in Tick's error (#214 question 8), which the Tick godoc now says. Checkpoints still grow with trace history, and the size metric #214 question 9 proposes has no home yet. DeliverToActor passes no effects to the scheduler, so a state entered by delivery never arms its timer. Tick doesn't absorb service or actor effects, so a timer entering an invoke state doesn't start the service live, and a timer that leaves and re-enters one can make Recover fail. Both exist on the base.

Why

Start never armed the initial state's timers, even live, so an instance starting in a timed state now fires a timer it didn't before. A timer fired after a checkpoint, or armed by a service result, was missed on replay. Every idle tick appended a Record.

Relates to: #214

Evidence

On GOTOOLCHAIN=go1.27.3, in durable:

Command	Result
go test ./...	Pass, including TestClock_StartInTimedState_ArmsTimer, TestClock_TickWithNothingDue_AppendsNoRecord, TestClock_TickWithNoTimer_AppendsNoRecord, TestService_TimerArmedBySettle_ReplaysOnRecover and TestTimerCheckpoint_FiredAfterCheckpoint_ByteIdentical
go test -race ./...	pass, 0 race warnings
Pinned golangci-lint	0 issues

Checklist

• Commits are signed off (git commit -s) per the DCO
• Conventional commit messages (type: subject)
• mage check passes locally (lint + race tests + govulncheck): not run as a whole
• Tests added/updated for the change: TestStateAt_TimerArmedAtStart_Fires, the older-journal TestRecover_OlderJournal_* tests, and the timer tests above
• Public API changes documented (godoc) and, if applicable, noted for the changelog

[reka18]

Review results. One reviewer per dimension, each reading the others' findings. All seven dimensions have zero blockers on the latest round.

Fixed along the way: the Handle's timer table now follows the scheduler, and each chained timer takes the deadline the scheduler armed. Replay aligns on each Record, so older journals with a misplaced settle read recover, including across a restart. Every fix has a test confirmed to fail without it.

Fuzzing journals this PR writes found no mismatch in about 80,000 operations per run.

Known limits, in the changelog: two kinds of older journal can't be repaired and can fail Recover. A failed timer transition is reported only in its FireResult (#214 question 8).