fix: preserve the capture clock epoch

[abrichr]

What changed

The first retained desktop frame used the recorder clock. When the screen thread started, it restarted that same clock. The next frame could then look older than the initial frame, and the Windows live seal was right to reject the capture.

The recorder process now initializes its clock once. Its screen, window, input, and processor threads keep that epoch. Child processes still initialize their own process-local clocks. This doesn't sort timestamps or relax video and seal validation.

Tests

• Added a deterministic interleaving test that reproduces the old clock rewind.
• Strengthened the no-action live test to require multiple retained frames with increasing capture times.
• The complete local gate passed: 594 tests passed, 2 skipped, and 12 slow or browser tests were excluded by the repository gate.
• Ruff and the diff check passed.
• An independent exact-head review found no P0-P2 issue.

An optional interactive macOS run on a two-monitor host hit the existing 30-second video-writer startup limit before it reached the clock assertions. The hosted Windows live run remains the platform gate for this fix.