test: freeze the open-bucket flush clock

[tonyalaribe]

The open-bucket force-flush regression can fail when wall time crosses a bucket boundary between inserting its fixture and flushing completed buckets. CI job102022757538 reproduced this at10:20:00 UTC: the completed-bucket flush legitimately drained the newly sealed bucket; retry passed.

Freeze the existing test clock, give the fixture an explicit matching timestamp, and restore wall time with the existing scopeguard dependency even on panic. Both original assertions remain: normal flushing leaves the open bucket, and forced flushing drains it. Production behavior is unchanged.

Validation: formatting and diff checks pass. Full CI is pending; the captured baseline failure is in timefusion-typed-ordering-shard2-passed.log.

[claude]

Review

This is a clean, well-targeted fix for the flake. Summary of what I checked:

Correctness of the fix

• flush_completed_buckets / force_flush_current_buckets both derive "now" from crate::support::now_micros(), which honors the frozen-clock seam. Freezing the clock up front and feeding that same value into the fixture's timestamp (via test_span_ts) guarantees the row and the flush logic agree on which bucket is "open," eliminating the race where wall time ticks past a bucket boundary between insert and flush. This directly matches the described CI failure (bucket sealed between fixture insert and flush check).
• Using scopeguard::guard((), |_| crate::support::unfreeze()) to restore wall-clock mode is consistent with the panic-safe pattern already used elsewhere in this file (e.g. the Unfreeze/Drop guard around line 6059) — good to use the crate directly here since scopeguard is already a dependency and already used elsewhere in mod.rs (line 3694), rather than reintroducing a bespoke Drop type.
• The test keeps #[serial], so it won't race with other #[serial] tests that mutate the same process-wide FROZEN_NOW static.
• Both original assertions are preserved (flush_completed_buckets leaves the open bucket; force_flush_current_buckets drains it), so the regression test still exercises the same behavior — just deterministically now.

Scope

• Test-only change, no production code touched, which matches the stated intent ("production behavior is unchanged").

Minor observations (non-blocking)

• A few sibling tests in this same file (e.g. around line 4492 and the set_micros/unfreeze pairs near 7510–7540) still call unfreeze() directly without a panic guard, so a leaked frozen clock from an assertion failure there could still bleed into later #[serial] tests. Not something this PR needs to fix, but might be worth a follow-up cleanup for consistency now that there's a nice precedent (the scopeguard idiom used here) to apply everywhere.
• The comment above the insert ("Row and flush clocks must stay in the same bucket even at a wall-clock boundary.") is good — explains the non-obvious "why" rather than restating the code.

No bugs, security, or performance concerns — this only affects test determinism. Nice minimal fix.