Fix flaky CanDoSortedSetExpireLTM by forcing eviction with FlushAndEvict

[tiagonapoli]

Problem

RespSortedSetTests.CanDoSortedSetExpireLTM (#1981) is flaky under CPU pressure and was observed failing in CI.

Root cause

The test sets per-field TTLs (small/large), then runs a 1000-key fill to force the records to spill to disk, and only afterward asserts that the small field has expired while the large field is still alive.

The fill is ~1000 sequential client→server round-trips, so its wall-clock duration scales inversely with available CPU. The original code added a fixed Task.Delay after the fill, so the elapsed time between ZEXPIRE and the first checkpoint was fill_time + delay. Under CPU pressure that exceeded the large field's TTL, so the large field legitimately expired before its "still alive" assertion — a test-timing bug, not a product bug.

Fix

Replace the fill with a deterministic eviction:

• Call server.Provider.StoreWrapper.store.Log.FlushAndEvict(wait: true) to flush the records to disk in one synchronous call. This is an idiom already used across the test suite (RespRangeIndexTests, CacheSizeTrackerTests, GarnetObjectTests).
• With no fill, there is no CPU-dependent work between setting the TTLs and the checks — the only elapsed time is the fixed Task.Delay, so the flakiness is removed at the root rather than papered over with larger timeouts.
• FlushAndEvict is called again before each checkpoint so every read is served from disk, still exercising the on-disk TTL deserialization path (SortedSetObject serialize/deserialize) that this test exists to cover.
• TTLs lowered to 2s / 4s (the fill is gone, so no time budget is needed to absorb it), and a dedicated non-expiring key verifies that unaffected data survives intact.

Note: adding more members to a single sorted set would not work — that grows one record in place and never evicts the TTL-bearing records. Eviction requires pushing those records below HeadAddress, which FlushAndEvict does directly.

Validation

Run in a CPU-throttled container: no failures across 37 runs at 0.25 CPU and 29 runs at full CPU.

Fixes #1981

[Copilot]

Pull request overview

This PR fixes CI flakiness in RespSortedSetTests.CanDoSortedSetExpireLTM by moving ZEXPIRE calls to occur after the larger-than-memory (LTM) fill loop, preventing the TTL budget from being consumed by CPU-dependent setup time.

Changes:

• Removed per-member ZEXPIRE calls from the initial key-setup loops.
• Added a post-LTM-fill block that applies the field expirations immediately before the test’s delay-and-assertion sequence.
• Documented the timing rationale inline (referencing #1981) to prevent regressions.