txn-wal: fix data loss in txns_progress_frontiers UP TO race

[antiguru]

Motivation

Fixes SQL-299.

The deasync rewrite in #36537 reordered the per-activation logic in txns_progress_frontiers so the passthrough frontier was applied (dropping the output capability when it crossed until) before the passthrough buffer was drained. If both happened in a single activation, any buffered batch was drained into the no-cap branch and silently discarded — visible to callers as missing rows at the tail of a SUBSCRIBE ... UP TO.

Description

• Drain the passthrough buffer first, at the capability held from the previous activation. That preserves the differential invariant send_time <= record_time (cap is the prior frontier, which is <= every record subsequently received) and guarantees buffered records are emitted before any until-driven cap drop.
• Replace the single retained DataRemapEntry with a VecDeque plus a latest_remap_log for frontier-only advances. The async original walked entries one at a time off the FIFO channel and could advance the cap stepwise at every physical_upper_i; the sync for_each flattens that into one activation, so the queue is needed to recover stepwise advancement and avoid stalling when pass_frontier sits between two entries' physical_uppers. latest_remap_log covers the case where the remap source downgrades its cap past the last emitted entry's logical_upper without producing a new entry — without it the operator deadlocks after consuming the queue because waiting_for_remap blocks pass_frontier from driving cap further.
• Adds a caller-facing contract on txns_progress_frontiers derived from the pre-txn-wal: deasync txns_progress_frontiers + retain remap across close #36537 async semantics, since the function had none.

Verification

• All existing mz-txn-wal lib tests pass (29/29), including as_of_until, data_subscribe, subscribe_shard_finalize, subscribe_shard_register_forget, and frontiers_advance_to_logical_after_remap_close.
• as_of_until test relaxed: now asserts the differential invariant (stream_ts <= record_time) and the set of records, instead of exact stream-timestamp matching. With the drain-at-current-cap approach the stream timestamp is a function of scheduling cadence rather than part of the contract.
• New regression test test-sql-299 in test/cluster: drives the SQL surface with a tight commit loop in parallel with SUBSCRIBE ... UP TO mz_now()+1 (with compute_subscribe_snapshot_optimization disabled to force the snapshot through the operator). On the buggy commit some iterations lose rows; with the fix every iteration returns the full count.

[antiguru]

Heads up: #36553 reverts both #36537 (this PR's target) and #36514 (container builders for the persist source). #36514 was merged on top of #36537 and propagated the sync txns_progress_frontiers signature through persist_source, so #36537 couldn't be reverted in isolation.

When this PR lands, both #36514 and #36537 will need to be re-applied on top of the fix (or rebased through it).