Migrate filter and search timestamp surfaces to Jiff

[danbi2990]

Background

TrafficFilter and Filter.period are both filter/search related surfaces with chrono timestamp values. TrafficFilter stores modification timestamps, while Filter.period can store custom search periods containing two DateTime<Utc> values.

Prerequisites

• Default bincode table value baseline has landed.
• The table-value implementation umbrella is open and linked.
• Old-byte fixture coverage for the exact TrafficFilter and Filter.period stored values exists before production type changes are made, or this issue adds that fixture coverage first.

Scope

• Migrate TrafficFilter.last_modification_time.
• Migrate TrafficFilter.update_time.
• Migrate PeriodForSearch::Custom used by Filter.period.
• Preserve stored bincode compatibility where possible.

Acceptance criteria

• Old TrafficFilter stored bytes remain readable, or data migration is explicitly implemented.
• Old Filter.period stored bytes remain readable, or data migration is explicitly implemented.
• Custom period range semantics are preserved.
• Public/API impact for filter/search wrappers is visible in tests or compile checks.
• Any remaining chrono usage in the touched filter/search surfaces is explicitly justified.

Out of scope

• Event query time filters outside these table values.
• Final chrono dependency cleanup.

Notes

Related discussion: #733

[octoaide]

Hi @sophie-cluml (and @sehkone),

This issue proposes migrating the chrono timestamp fields used by filter/search surfaces to Jiff (TrafficFilter.last_modification_time, TrafficFilter.update_time, and Filter.period's PeriodForSearch::Custom) while preserving bincode compatibility or providing a migration. A few facts and quick checks:

• The prerequisite Add baseline tests for default bincode table values with chrono fields #746 is closed, so that baseline step appears satisfied. Thank you for that.
• The issue mentions an umbrella "table-value implementation" and "old-byte fixture coverage" as prerequisites. Could you confirm whether the umbrella issue and the specific old-byte fixtures for TrafficFilter and Filter.period already exist and are ready for this migration? If they do, please point me to them.

I can help move this forward but I won't start implementing while this issue is still assigned to you unless you explicitly delegate the work to me. Please let me know which of the following you prefer:

1. You (or someone on the team) will continue with the implementation. If so, could you give a short status update and/or ETA and confirm the fixture coverage is present?
2. You delegate the implementation to me / allow me to create the PR. If you choose this, please either unassign yourself or reply here saying you delegate to me; I will then: a) add old-byte fixtures if missing, b) implement the chrono -> Jiff migration for the three targets, ensuring old bytes remain readable or documenting+implementing a migration path, and c) include tests that assert API/semantics are preserved.

If helpful, I can first post a short proposal of sub-tasks (one self-contained work item: implement migration for the three values with tests and fixtures) and then open a single PR implementing them. Please react with 👍 to approve that I should prepare the sub-issue + PR plan, or reply here with your preferred next step. Thanks!