refactor: introduce generation run state model

[jayscambler]

Summary

• introduce a dedicated generation run state-transition module for GenerationRunner
• move run bookkeeping into pure state helpers with direct tests
• keep runner behavior stable while preparing for future state-machine work

TDD / DDD / DRY framing

This is the next stacked architectural PR after #651.

Bounded context extracted:

• Generation Run State — run lifecycle bookkeeping for status, best score, current Elo, pending fresh-start hints, and run timestamps

Test-first work:

• added state-transition tests first
• implemented pure run-state helpers
• rewired GenerationRunner to use the extracted state model

Changes

New module

• ts/src/loop/generation-run-state.ts
  • createGenerationRunState
  • recordGenerationResult
  • queueFreshStartHint
  • consumeFreshStartHint
  • completeGenerationRun
  • failGenerationRun

New tests

• ts/tests/generation-run-state.test.ts
  • run creation defaults
  • generation result transitions
  • one-shot fresh-start hint consumption
  • completion/failure state transitions

Runner integration

• ts/src/loop/generation-runner.ts
  • delegates run bookkeeping to the extracted state module
  • consumes fresh-start hints through the state transition helper
  • derives completion/failure metadata from the run-state object

Validation

• cd ts && npx vitest run tests/generation-run-state.test.ts tests/generation-loop.test.ts tests/generation-journal.test.ts tests/generation-recovery.test.ts tests/generation-runner-prompts.test.ts
• cd ts && npm run lint

Why this matters

This does not introduce XState yet. It is the intermediate step that isolates the generation-loop lifecycle as a state model first, so a future state-machine PR can be evaluated on top of an explicit transition surface instead of a giant mutable class.