mcpdo: bring --load-connections and the --load-max-* thresholds to tools/call --load #2800

Follow-up to #2744 / #2786, which brought --load to mcpdo tools/call. While that PR was in review, two more load features landed in the one-shot CLI, on the same shared engine:

• CLI --load: opt-in error-rate / latency thresholds that set the exit code (for CI) #2745: --load-max-error-rate <fraction> / --load-max-p99 <ms> set the exit code when a run breaches a threshold (core/cli/handlers/load-thresholds.ts).
• CLI --load: multi-connection mode (--load-connections) to test many sessions, not one #2746: --load-connections <n> spreads a load run's workers over n independent sessions instead of one (runLoadAcrossConnections in core/cli/handlers/load-test.ts).

mcpdo tools/call --load currently exposes only the original four bounds, so the two CLIs have drifted apart. This issue brings both features to mcpdo.

What

Thresholds (--load-max-error-rate, --load-max-p99)

• Add both flags to tools/call, using the CLI's own parsers (fractionParser, maxP99Parser). Each one requires --load, matching the CLI's rule.
• Evaluate them in the front-end, after the summary has been written, using resolveLoadThresholds / checkLoadThresholds. That is the same order the CLI uses, so a breached run still prints its numbers. The daemon doesn't need to know about thresholds, because they judge a finished summary rather than bound the run.
• A breach surfaces as mcpdo's error envelope, with the same codes as the CLI (load_error_rate_exceeded, load_p99_exceeded) and the same exit code.

Multiple sessions (--load-connections)

• Add the flag, validated the way the CLI validates it (resolveLoadOptions already refuses connections > concurrency).
• In the daemon, give runToolLoad an openConnection that dials a fresh InspectorClient for the extra sessions. It should use the stored connection's serverConfig / serverSettings, with stored auth only, so it never starts an interactive sign-in mid-run. The engine already opens the extras before the clock starts and closes them in a finally.
• The connection's own live client remains the primary session, and the per-connection rpc queue behavior is unchanged.

Open questions

• Extra sessions and the daemon's bookkeeping. The extra sessions are short-lived, owned by the run, and never registered as connections. Confirm they stay invisible to connections/list and to idle-shutdown accounting, and that a daemon shutdown mid-run closes them.
• Cancellation. feat(mcpdo): add tools/call --load on the shared load engine #2786 aborts a run when its caller hangs up. Check that the extras' in-flight calls cancel too: they need the ambient request signal set on each extra client, not only on the primary.

Priority score

Severity 2 (the one-shot CLI does both today, so it's minor friction) + urgency 2 (wanted eventually; nothing waits on it) + 1 (milestoned) = 5 → Low.