fix(runners): wire job_retry.lambda_memory_size and lambda_timeout

The job_retry variable on both the multi-runner and runners modules
declares lambda_memory_size and lambda_timeout, but the
local.job_retry map in modules/runners/job-retry.tf never copied
either field into the config passed to the inner job-retry / lambda
sub-modules. The inner lambda module fell back to its defaults
(memory_size = 256, timeout = 60), so user-supplied values were
silently dropped.

Mirrors the pattern already used by ssm-housekeeper.tf
(local.ssm_housekeeper.lambda_memory_size /
local.ssm_housekeeper.lambda_timeout) — the ssm-housekeeper Lambda
correctly threads the values through; the job-retry one didn't.

Observed in production: a deployment pinned to lambda_memory_size = 512
in multi_runner_config[*].runner_config.job_retry produced no plan
diff because the value never reached the resource. The job-retry
Lambdas were OOM-adjacent at 87% memory utilisation (223 MB peak on
the 256 MB default) on a fleet of three runners.

Author: oscarbc96

modules/runners/job-retry.tf

@@ -30,6 +30,8 @@ locals {
     ghes_url                                                       = var.ghes_url
     lambda_event_source_mapping_batch_size                         = var.lambda_event_source_mapping_batch_size
     lambda_event_source_mapping_maximum_batching_window_in_seconds = var.lambda_event_source_mapping_maximum_batching_window_in_seconds
+    memory_size                                                    = var.job_retry.lambda_memory_size
+    timeout                                                        = var.job_retry.lambda_timeout
   }
 }