fix(runners): pace Parameter Store writes against the account-wide limit

[atsikham]

Fixes #5410

Summary

The code that slows down writes to Parameter Store (so they don't hit AWS's rate limit) had two problems:

1. It only started slowing down writes once a single Lambda invocation's own batch of runners reached the store's maxWritesPerSecond number, and it based the delay only on that one invocation's batch size. But Parameter Store's write limit applies to the whole AWS account, not to one invocation: several pools can each run their own scale-up/pool Lambda at the same time, each one under its own threshold, while their writes added together go over the account's limit. And a batch smaller than the threshold got no slowdown at all.
2. The write limit itself was hardcoded to SSM's default of 40 writes/second, with no way to reflect an account that turned on SSM's higher-throughput setting, which allows a lot more.

Changes

• The code now always slows down writes once a write limit is set on the store, no matter how big or small this invocation's batch is.
• A new Terraform variable, ssm_parameter_store_max_concurrent_invocations, sets how many scale-up/pool Lambda invocations can realistically be running at the same time across the whole deployment. The delay between writes is divided by that number, so the account-wide write budget is shared across all of them instead of each invocation assuming it has the whole budget to itself.
• A new Terraform variable, ssm_parameter_store_max_writes_per_second, makes the actual write-rate limit configurable instead of it being fixed at 40. If an account turns on SSM's higher-throughput setting, this can be raised to match the real limit.
• Both variables are wired up for the scale-up and pool Lambdas. The defaults (1 invocation, 40 writes/sec) match how the code behaved before.
• docs/rate-limits-and-tuning.md is updated: the Parameter Store section now explains both new variables, and points out that turning on AWS's higher-throughput setting by itself does nothing — ssm_parameter_store_max_writes_per_second also needs raising, or the code keeps slowing writes down to the old default. Also fixed a claim in the batch_size table that was no longer true (the slowdown no longer depends on batch size), and updated the advice for large deployments.

One thing left out on purpose: this only connects the new variables in modules/runners (the main scale-up + pool setup). The webhook-orchestration and multi-runner-v2 setups were not touched. This could be extended if wanted.

Test plan

• yarn test — github-runner.test.ts checks the delay math in addDelay (including the small-batch case that used to get no delay, and the sharing-across-invocations behavior), plus an end-to-end test using fake timers through createStartRunnerConfig. runner-config-store.test.ts and storage-providers.test.ts check that the write-rate limit can be set, falls back to 40 if the value is missing or invalid, and is picked up from the environment correctly.
• yarn lint / yarn format
• tsc --noEmit
• terraform fmt -check / terraform validate (tflint could not be installed in this environment — no network access to its Homebrew source — so the full set of pre-commit checks was not run locally)

[edersonbrilhante]

@atsikham also implement the changes in https://github.com/github-aws-runners/terraform-aws-github-runner/tree/main/modules/orchestration-providers/webhook and https://github.com/github-aws-runners/terraform-aws-github-runner/tree/main/modules/multi-runner

multi-runner is the module to deploy multi runners
orchestration-providers/webhook is the module v2 to configure pool/scaleup for a runner

[atsikham]

@edersonbrilhante digging into the wiring: in modules/runners the two new pacing settings are one flat value shared by scale-up and pool lambda. But multi-runner/orchestration-providers/webhook split lambda config per type with no shared bucket. Duplicate the field under both scale.up and pool, or is there a preferred place for settings shared across lambdas in a runner group?