storage sink: avoid interval flush sweeping fresh table batches

Problem

Cloud storage sink currently uses flush-interval as a periodic sweep at the writer shard level. When the ticker fires, the buffer manager flushes all table batches currently held by that writer shard.

In a workload with many tables, this can create many small files: a table batch may have just received its first entry but still be flushed immediately because it happens to be present when the shard-level interval tick fires.

The desired behavior is closer to per-table batch max age: each table batch should be flushed by interval only after its own oldest entry has waited for roughly flush-interval.

Why this matters

The current sweep semantics reduce latency, but in high-table-count workloads they can cause excessive small files and amplify external storage write latency. This makes cloud storage sink throughput more sensitive to S3 request latency and can keep writer workers busy even when byte throughput is not high.

Notes

An experimental batch-per-age change was tried during OOM investigation, but it is not included in the release-8.5 cherry-pick because it changes interval flush semantics and needs a more careful design/review. The immediate OOM fix should stay focused on reducing retained memory.

A future implementation should preserve the original purpose of flush-interval:

• prevent unbounded wait time for low-traffic tables
• avoid keeping spool entries and callbacks forever
• avoid flushing a table batch before it has actually reached its own interval age
• avoid introducing excessive timers or goroutines for many tables

Possible direction

Use an event/deadline-driven timer based on the earliest table batch deadline (firstEntryAt + flushInterval) instead of a fixed shard-level sweep. When the timer fires, flush only expired table batches and then re-arm the timer for the next deadline.

Start by tracing the cloud storage sink's writer shard, buffer manager, and current flush-interval ticker behavior. Define the earliest per-table batch deadline, flush only expired batches, and re-arm for the next deadline while avoiding excessive timers; done means low-traffic tables still flush on time without sweeping fresh batches or creating excessive small files.