Align client latency measurements around transaction submission

## Outcome

RedSuite's load scenarios report client-observed latency from one consistent transaction-submission boundary, without attributing client transport delay to validator processing.

## Scope

- Capture one timestamp immediately before `sendTransaction` and use it for delivery, signature-confirmation, and account-update latency.
- Keep transaction preparation, blockhash refresh, and subscription setup outside that measurement.
- Continue including Reqwest connection-pool, transport, network, and response-processing time; do not attempt to detect when bytes reach TCP.
- Report admission-to-task-start delay and use offered versus achieved rate plus validator metrics to identify client-saturated runs.
- Keep the implementation within RedSuite and preserve comparison with existing stored reports.

## Acceptance criteria

- [ ] Delivery, signature-confirmation, and account-update latency share the same per-transaction start time immediately before HTTP submission.
- [ ] The metric descriptions identify these values as client-observed rather than validator-only latency.
- [ ] Client scheduling delay is reported separately from request latency.
- [ ] A run that cannot sustain its offered rate or shows client-side saturation is not presented as a validator latency regression.
- [ ] Existing reports remain readable and comparable after any metric-label changes.