fix: enable Octokit throttle retry and SSM adaptive retry under burst

[vegardx]

Problem

Two resilience gaps that compound under burst load:

1. Octokit throttle plugin never retries — onRateLimit and onSecondaryRateLimit callbacks log a warning but don't return true, so @octokit/plugin-throttling throws immediately instead of retrying after the retryAfter delay.

2. SSM client uses default retry (standard, 3 attempts, ~3s budget) — under burst with multiple concurrent Lambdas writing JIT configs via PutParameter, SSM's ~40 TPS limit is easily exceeded and ThrottlingException propagates up, failing the entire batch.

Fix

Octokit throttle callbacks return true with caps

onRateLimit: (retryAfter, options) => {
  logger.warn(`...retrying after ${retryAfter}s`);
  return options.request.retryCount < 2; // retry up to 2x on primary rate limit
},
onSecondaryRateLimit: (retryAfter, options) => {
  logger.warn(`...retrying after ${retryAfter}s`);
  return options.request.retryCount < 1; // retry once on secondary/abuse limit
},

SSM adaptive retry with maxAttempts=10

const SSM_CLIENT_CONFIG = {
  region: process.env.AWS_REGION,
  maxAttempts: 10,
  retryMode: 'adaptive' as const,
};

adaptive mode adds client-side rate-sensing — when the SDK sees ThrottlingException it slows further calls to match the observed budget. 10 attempts gives ~30s of retry budget, which is safe because runners take ~30-50s to boot before reading their JIT config.

Changes

• lambdas/functions/control-plane/src/github/auth.ts — throttle callbacks return true with retry caps
• lambdas/libs/aws-ssm-util/src/index.ts — shared SSM client config with adaptive retry

Impact

Scenario	Before	After
GitHub rate limit during scale-up	Request fails immediately	Retries 1-2x with backoff
SSM throttle during JIT config write	ThrottlingException after ~3s	Adaptive backoff for ~30s
Burst of 100 jobs, batch_size=10	SSM throttle → orphaned instances	Retry absorbs throttle

Fixes #5135
Refs: #5024, #5037