Limits harness: two-tier topology composer (aggregating Shipper stack)

[Minipada]

Parent

#323

What to build

The two-tier topology composer: bring up, with plain podman (matching the existing E2E harness's container-lifecycle convention, not compose, since scenarios control container lifecycle mid-run), an aggregating Shipper, an object-storage Destination, a database Destination, N real DC stacks, and M synthetic senders (the load driver), all reusing the existing workspace image. This ticket is verifiable on its own, before any ramping logic exists: at a fixed, non-saturating load, the existing zero-loss verifier must pass against this new two-tier topology, proving Records survive the extra hop.

Acceptance criteria

• A scenario script (sibling of the existing zero-loss/retention scripts under tools/e2e/scripts/) stands up the two-tier stack via podman and tears it down on both success and failure, following the existing cleanup / keep-for-debugging convention.
• At a fixed nominal load (real stacks plus synthetic senders together, well below any saturation point), the existing zero-loss verifier passes end-to-end through both Shipper tiers.
• No new DC code is required — the Bridge's existing remote-Shipper-target support and the Shipper's existing at-least-once / dedup-on-read behaviour are exercised unmodified across the extra hop. If that assumption turns out false, that discovery is recorded rather than worked around silently.

Blocked by

• Limits harness: synthetic load driver (shipper ingest protocol sender) #378 (synthetic load driver)

[Minipada]

Closed by #401 (merged into jazzy).