feat(multi-runner): add experimental config translation

[edersonbrilhante]

Description

• Split the experimental configuration into typed global, provider-specific, and multi-runner inputs.
• Translate stable v1 inputs into the experimental schema and resolve lane overrides against the selected global configuration.
• Route runner, queue, webhook matcher, IAM, observability, and SSM settings through local.resolved_config.
• Preserve stable v1 compatibility while allowing an experimental v2 lane map to drive resource creation.
• Add coverage for experimental resource selection and remove the unused module-level iam_overrides input.

Test Plan

• terraform fmt -recursive
• terraform validate in modules/multi-runner — passed with existing ami-housekeeper deprecation warnings
• terraform test in modules/multi-runner — 6 passed, 0 failed
• Pre-commit hooks passed: Terraform fmt, Terraform validate with TFLint, and merge-conflict checks

Related Issues

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[Brend-Smits]

Really like the direction here, and the ADR is excellent. One design worry: baking experimental_ into every variable name means anyone who helps test this, or adopts it once a migration path exists, has to rename their whole config again at graduation. That penalizes exactly the early adopters we want.

Could we instead treat instability as a lifecycle property, not a naming one?

• Give the config its intended permanent names now (global_config, global_config_observability, multi_runner_config, …).
• Gate opt-in behind a single acknowledgement flag, e.g. experimental_features = ["multi-runner-v2"], with a validation that errors if the v2 config is set without the ack.
• Communicate "this may break" via the docs banner, description warnings, and semver on the schema during the experimental window.

Then graduation is just dropping the flag (kept as a deprecated no-op for one release), the user's actual config blocks never change. It also fits the ADR's goal of a stable provider boundary: the boundary shouldn't be spelled experimental_ in every consumer's HCL.

Fair trade-off: the prefix does make instability impossible to miss and keeps v1/v2 unambiguous in locals/state, the gate approach reproduces that via validation instead of naming. I think that's worth it to avoid the double migration.

What do you think?