fix: do not count downtime towards crawler_runtime after migration or resurrection

[Pijukatel]

Description

When a crawler run is resumed from a persisted state (Actor migration or resurrection), the reported crawler_runtime was inflated by the downtime between the runs, in several ways:

• Statistics.__aenter__ started the periodic logger while crawler_last_started_at still pointed at the previous run's start, so the first statistics log of the resumed run included all the downtime between the runs. Later stats were computed from the new start time, which made the value appear to jump from a large number (e.g. 38s) back down to the real runtime (e.g. 542ms). The run timestamps are now reset before the periodic logger starts and the new start time is set after the initial log entry, so the first log reports exactly the runtime accumulated so far: zero for a fresh start, the previous total for a resumed run.
• When the persisted state came from a run that did not finish cleanly (migration, abort), StatisticsState.model_post_init computed the accumulated runtime offset using the current time, so the downtime was permanently baked into all subsequent statistics of the resumed run.
• The offset was reconstructed only from the last run's timestamps, so with two or more resurrections, the runtime of all runs before the most recent one was silently dropped from the total.

The accumulated runtime is now restored directly from the persisted crawlerRuntimeMillis value, which is correct for both clean and unclean shutdowns and accumulates across any number of resurrections. The timestamp-based reconstruction is kept as a fallback for states persisted by older versions, using stats_persisted_at (the moment the state was last saved) to approximate when an uncleanly finished run stopped. crawlerRuntimeMillis is also serialized as milliseconds now, matching its name and the other *Millis fields, instead of an ISO 8601 duration string.

Issues

• None filed; reported via a resurrected Actor run log where the initial statistics table showed crawler_runtime of 38.01s that later dropped to 542.8ms.

Testing

• Added regression tests in tests/unit/_statistics/test_persistence.py: the first periodic log of a fresh run reports exactly zero, the first log of a resumed run reports the previous runtime without a simulated 2-hour downtime, the runtime offset stays correct after an unclean shutdown, and the total runtime accumulates across multiple resurrections instead of keeping only the last run's segment. All fail without the fix and pass with it.
• poe lint, poe type-check, and the statistics and basic-crawler unit tests pass locally.

Checklist

• CI passed

🤖 Generated with Claude Code

https://claude.ai/code/session_01VMHwDx87jV4rnu5LkbpNxy

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.74%. Comparing base (142ec58) to head (5c119b1).
⚠️ Report is 6 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2204   +/-   ##
=======================================
  Coverage   93.74%   93.74%           
=======================================
  Files         181      181           
  Lines       12852    12853    +1     
=======================================
+ Hits        12048    12049    +1     
  Misses        804      804           

Flag	Coverage Δ
unit	93.74% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.