Keep per-thread trace timestamps monotonic

[namtran1812]

Summary

Prevent backwards per-thread event timestamps from producing invalid trace durations during decoding.

Fixes #319.

Problem

The streaming trace writer assumes that event time for a given thread is monotonic, but that invariant was not enforced.

When an event arrives with a timestamp older than one already processed for the same thread:

• last_event_time moves backwards
• pending-event flushing can operate over a negative time interval
• open callstack frames can later be closed at a timestamp earlier than their start

This can ultimately produce errors such as:

duration_complete event must have start tick (...) greater than end tick (...)

Implementation

Normalize incoming per-thread event timestamps at the event_time boundary:

• preserve stream processing order
• keep the writer's logical per-thread time monotonic
• prevent pending-event flushing from operating over negative intervals
• keep callstack reconstruction and thread-end timestamps on the same ordered timeline

The fix intentionally lives at timestamp normalization rather than clamping individual duration writes.

Tests

Added a deterministic regression case with:

• call at 200 ns
• nested call at 300 ns
• return event at 150 ns

The trace writer must serialize this stream successfully instead of producing an invalid backwards duration.

Validation

• dune build @fmt passes locally
• git diff --check passes locally
• full inline tests cannot currently run in the local macOS switch because Jane Street test-only dependencies are unavailable there

Opening as draft pending upstream Linux CI validation.