Unify parallel recovery adjustments

[hemanth-asirvatham]

Motivation

• Reduce ping-ponging between separate rate-limit and connection-error handlers by making upward and downward concurrency adjustments unified and consistent.
• Make re-increase of parallelism more gradual to avoid overshooting after transient spikes.
• Use more conservative default ramp settings to avoid aggressive early scaling (ramp_up_seconds -> 15.0, ramp_up_start_fraction -> 0.2).

Description

• Added time_of_last_connection_error to StatusTracker and update it wherever connection errors are recorded to allow unified recovery decisions.
• Replaced the two separate adjustment flows with a single maybe_adjust_concurrency() that combines recent rate-limit and connection-error windows, computes combined thresholds, and performs unified scale-down/scale-up with clearer logging.
• Wired existing connection-error handlers to use the unified maybe_adjust_concurrency() and tuned the scale thresholds and step sizes (combined error window, adjusted error_window_threshold, consecutive_threshold, slower success_threshold, and smaller increments).
• Updated safe-to-increase checks and throughput-tuning logic to consult status.time_of_last_connection_error and to clear both error deques when scaling down, plus small wording changes in emitted messages.

Testing

• No automated tests were run as part of this change (no test run was requested).

---

Codex Task

[github-actions]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}