chore(deps): lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Configuration

📅 Schedule: Branch creation - "before 4am on monday" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Caution

[High Risk] Target group replacement can temporarily leave both load balancers with no healthy backends

The change replaces both 540044833068.eu-west-2.elbv2-target-group.api-health-terraform-example and 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg, and the only concrete companion change shown is creation of a fresh aws_lb_target_group_attachment for api-health-terraform-example on port 9090. In AWS, a target group's target_type determines what can be registered, and target groups cannot change that mode in place, so replacement is the moment where registrations and health state are torn down and rebuilt. If the new target group is not fully attached and healthy before listener cutover, the load balancer will forward to an empty or unhealthy target set.

This is especially risky for api-207c90ee-tg because the affected API path appears to have only a single backend instance in the visible blast radius, with inbound access tightly scoped to port 80 from the ALB security group. A detach/reattach window during replacement will therefore remove the only healthy target instead of being masked by multi-target or multi-AZ redundancy, causing user-facing API traffic loss. For api-health-terraform-example, the replacement similarly risks temporary loss of the internal health endpoint until the new ip target registration on port 9090 is recreated and passes health checks.
_{View reasoning tree here.}

Warning

[Medium Risk] Simultaneous instance and target-group replacement will create a production brownout window with weaker alerting

This change refreshes several production API EC2 instances while also replacing both target groups they depend on. The current live groups show two different health contracts in service today: api-207c90ee-tg is an ALB HTTP target group checking /health on port 80, and api-health-terraform-example is an NLB TCP target group on port 9090. The new api_access instance is rebuilt with different bootstrap behavior and is only attached to the replacement health target group after boot. Because the instances and the target groups are being replaced together, existing healthy registrations cannot carry forward in place, so there is a real convergence window where new hosts must boot, register, and pass health checks before the new groups have healthy capacity. That creates a production brownout risk if bootstrapping is slow or the new AMIs regress.

At the same time, observability is weaker during the cutover. The api-207c90ee-high-cpu alarm is being rebound away from a fixed instance ID during the same rollout, and the new SNS email subscription on production-api-alerts is created with protocol=email and endpoint_auto_confirms=false, which means it will remain pending until someone confirms it. If the rollout causes unhealthy targets or instance-level issues during this window, alert delivery will be less reliable exactly when the deployment is most likely to fail.
_{View reasoning tree here.}

Signals

Routine → Multiple AWS infrastructure resources showing unusual and infrequent change patterns, with EC2 instances, an SNS subscription, an Elastic IP, and a load balancer target group attachment changing only 1-2 events/week for the last 3 months; a CloudWatch alarm also shows just 1 event/week for the last 2 months.
Policies → Infrastructure resources are showing unusual policy violations that may need review: an S3 bucket does not have server-side encryption configured and is missing required tags, while a security group allows SSH (port 22) access from anywhere (0.0.0.0/0).

_{Additional Change Details:} Items 133 Edges 228 model|risks_v6 ✨Encryption Key State Risk ✨KMS Key Creation

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 7 · Edges 23

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 2 high risks requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 2 · Medium 0 · Low 0

---

💥 Blast Radius

Items 83 · Edges 189

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 1 high risk requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 1 · Medium 1 · Low 0

---

💥 Blast Radius

Items 92 · Edges 260

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Found 2 high risks requiring review

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 2 · Medium 0 · Low 0

---

💥 Blast Radius

Items 57 · Edges 126

---

View full analysis in Overmind ↗