test(e2e): deflake epochs_mbps_redistribution

[spalladino]

Motivation

e2e_epochs/epochs_mbps_redistribution asserted that a burst of late txs all land in a single (last) block of a checkpoint. But the proposer snapshots the mempool once per block as soon as minTxsPerBlock are available, and the burst (sent via Promise.all(send())) reaches the proposer over gossip one tx at a time — so the last block's snapshot routinely captured only a subset and the rest spilled into the next checkpoint, flaking the assertion. Empirically the one-before-last block grabs its full redistributed allotment, leaving the last block with fewer than its static share, so "all in the last block" was never a reliable invariant in the first place.

Approach

Check the redistribution claim against a race-robust invariant rather than an exact block placement:

• Use a 4-block-per-checkpoint profile (blockDurationMs 8000 → 6000, slot unchanged at 36s) with a tight maxTxsPerCheckpoint = 9, giving a static per-block cap S = ceil(9 * 1.2 / 4) = 3 under the 1.2 multiplier floor.
• Two early blocks take one tx each; the 7-tx burst is dumped immediately after the second early block is in, then splits arbitrarily (x / 7 - x) across the last two blocks as it propagates.
• Assert that, within the checkpoint holding the early txs, the last two block indices jointly hold all 7 late txs (> 2 * S = 6). Without redistribution each block is capped at S, so the two could hold at most 6 and the 7th spills into the next checkpoint. The count is by checkpoint-relative block index (not global block number) so a spilled tx can't masquerade as redistributed, and the checkpoint block count is asserted to be 4 so a build collapse fails diagnostically rather than misleadingly.

This removes the dependence on which of the last two blocks wins the race. Verified robust by temporarily forcing the one-before-last block to both extremes (1 and 5 txs) — the joint count stays 7 in both cases.

Changes

• end-to-end (tests): rework the first epochs_mbps_redistribution test (C=4, immediate burst dump, joint last-two-blocks assertion) and refresh its comments; update the second test's comments to reflect the shared C=4 timing (its logic and assertions are unchanged).

Related: this investigation surfaced a separate production bug (A-1251) where waitForMinTxs gates on a non-age-filtered pending count while the block-building iterator filters by minTxPoolAgeMs; that is tracked separately and not addressed here.

This PR is an alternative to #24101