Symptom

A stored recording showed Capturado 2m57s ≈ Reproducción 2m41s (1×) when ~6× compression is expected. The watermark on the frame read 11:50 while the recording was labeled 17:54–17:57 — a ~6h gap.

Diagnosis (verified)

• The video is correctly compressed: seg_010236.ts is 6 frames + tail = 7.0s at 1fps, and the camera captures every ~6.4s. Segments are fine.
• The recording's start/end/duration come from SessionData timestamps, which are set to datetime.now() — processing time. These were backlog frames (captured ~11:50, processed ~17:54), so the recording showed the 3-min processing window, making the ratio look 1×.

Not caused by the throughput changes — it's the pre-existing session metadata using wall-clock, exposed by backlog draining.

Fix (PR #31)

Track the frame's capture time (request_timestamp) as separate session bounds and use them for the archive's displayed start/end/duration. Wall-clock is kept for offline detection and retention/expiry (so backlog archives don't expire instantly and offline detection still works).

Acceptance

• Recording start/end/duration reflect capture time, even during backlog drain.
• Offline detection + archive expiry still use wall-clock.
• Back/forward compatible session deserialization.
• Lint/type/tests pass.