Consolidate bounded fixture preparation

## Outcome

Repeated funding, account preparation, clone readiness, and causal pair-model behavior have authoritative implementations.

## Scope

[Core payer preparation](https://github.com/magicblock-labs/redsuite/blob/06c80157f8bc87c39ac48fd59367a8e9280d2db9/crates/redsuite-core/src/prep.rs#L27) is serial, while [conflict ordering](https://github.com/magicblock-labs/redsuite/blob/06c80157f8bc87c39ac48fd59367a8e9280d2db9/redline/src/scenarios/scheduler/conflict_ordering.rs#L932) implements its own concurrent funding and clone-wait loops. [Replication recovery](https://github.com/magicblock-labs/redsuite/blob/06c80157f8bc87c39ac48fd59367a8e9280d2db9/redshift/src/scenarios/replication/replication_recovery.rs#L477) repeats preparation and shares a duplicated causal pair model with conflict ordering.

Add bounded concurrency to core funding helpers. Consolidate repeated program-specific preparation and the shared pair model with their owning fixture support. Keep scenario assertions and expected outcomes local. This covers remaining duplication after #38, not its completed lifecycle/committee/token scope.

## Acceptance criteria

- [ ] Migrated callers reuse common implementations with deterministic output ordering.
- [ ] Preparation concurrency is bounded and errors retain useful context.
- [ ] Seed allocation, account authority, and required transaction ordering remain correct.
- [ ] Cold-cloning measurements and deliberate serial operations remain unchanged.
- [ ] The shared causal pair model has one implementation without moving scenario-specific verdicts into fixture helpers.