orchestrator: `load` in client-parameters.yml is silently ignored for remote benchmarks

Problem

LoadGeneratorConfig (the type behind client-parameters.yml) exposes a load field with a default of 10 tx/s:

# client-parameters.yml
load: 200            # <- looks like it sets the rate
transaction_size: 512
initial_delay: 30s

But for remote benchmarks the value is dead: RemoteBenchmarkDriver overwrites it unconditionally from the CLI --loads sweep at deploy time:

// crates/cli/src/remote/protocol.rs:120
load_generator_config.0.load = parameters.load / parameters.nodes;

So whatever the user writes for load in the parameters file is silently discarded. Meanwhile transaction_size and initial_delay from the same file are honored, and for local-testbed runs load is used — so the same field is live in one path and ignored in another, with no signal to the user.

Why it's confusing

• The field is documented (/// The number of transactions to send to the network per second.) and has a default, so it reads as authoritative.
• A user setting load: in client-parameters.yml for a remote sweep gets no warning that it has no effect; the real knob is the --loads CLI flag.

Options

1. Document it: note on the --loads arg and in client-parameters.yml that load is overridden per-run for remote benchmarks (the file value seeds only local runs).
2. Honor the file as a default: only override when --loads is explicitly given, so the file value is a real fallback.
3. Remove load from the remote client-parameters surface entirely, so the override site is the single source of truth and the field can't mislead.

(3) or (2) removes the footgun; (1) is the minimal fix.

Found while setting up an Orcaella f=0/c=1 remote benchmark.