Remove remaining chrono dependency after Jiff migration

[danbi2990]

Background

This cleanup should happen only after the compatibility baselines, Jiff implementation issues, required data migrations, and downstream-facing checks have landed.

The goal is to remove chrono from production code without losing compatibility fixtures or old schema migration structures that still need to describe historical stored bytes.

Prerequisites

• Event key and event stored-field baselines have landed.
• Default bincode table value baseline has landed.
• String timestamp baseline and migration have landed.
• column_stats baseline and implementation have landed.
• ModelIndicator.last_modification_time ts_seconds baseline and implementation have landed.
• Remaining public metadata and final chrono call-site implementation has landed.
• Jiff implementation issues for touched public/API and stored-data surfaces have landed.
• Required downstream-facing checks are complete or explicitly documented.

Scope

• Remove direct chrono usage from production code.
• Remove the direct chrono dependency if it is no longer needed outside compatibility fixtures or old migration structures.
• Keep chrono only where it is explicitly needed to represent historical schemas or compatibility fixtures.
• Run a compile-surface check to confirm no unexpected direct chrono surface remains.

Acceptance criteria

• Production code no longer requires chrono.
• Any remaining chrono usage is limited to compatibility fixtures, tests, or old data migration structures, and is explicitly justified.
• cargo check --message-format=json or an equivalent compile-surface check confirms no unexpected direct chrono usage remains.
• Relevant test suites pass.
• The PR description lists any intentionally retained chrono usage.

Out of scope

• Changing stored byte contracts.
• Adding new data migrations unless a previous issue explicitly left one for cleanup.
• Backward-write compatibility.

Notes

Related discussion: #733