fix(logs): bound saved activity by scan completion

[sylvesterkaczmarek]

Summary

Keep saved scan activity logs bounded by the scan's recorded completion time so same-thread post-scan events are not presented as scan history.

Fixes #555.

Reproduction / evidence

Current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba uses completedAt while deciding whether independent Deep worker sessions belong to a scan, but after sessions are selected it appends every event from those sessions without checking the completion boundary.

The SDK lifecycle completes and persists the scan first, then, when a postScanPrompt is configured, invokes that follow-up on the same Codex thread.

A root session with events at 08:01, scan completion at 08:02, and a post-scan event at 08:03 therefore currently returns both events from readScanLogs().

Root cause

The saved completion timestamp was enforced at the session-selection boundary but not at the per-event projection boundary.

Fix

• parse a finite saved completedAt once for event projection;
• omit timestamped events strictly after that instant from every included session;
• preserve running-scan behavior when completedAt is null;
• preserve legacy events that do not carry a usable timestamp.

Tests / validation

Added scan-logs-completion.test.ts with a single root-session fixture containing:

• a timestamped event before completion;
• a timestamped same-thread event after completion;
• an untimestamped legacy event.

The regression requires the pre-completion and legacy events to remain while the post-completion event is excluded.

The branch is based directly on current upstream main at 37bf87a692fc72d41f7312cc48808d699d204fba and is not behind it. Production change: 11 additions, 0 deletions.

Full repository tests cannot be run in this execution environment because the repository cannot be cloned here. Pushed-head CI remains the authoritative full-suite validation.

Risk

Low. The change only narrows completed saved logs when both the scan completion time and an event timestamp are valid. Running scans and legacy untimestamped rollout records retain their prior behavior.