Lock file maintenance

[renovate]

This PR contains the following updates:

Update	Change
lockFileMaintenance	All locks refreshed

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

---

Configuration

📅 Schedule: (in timezone Europe/London)

• Branch creation
  • "before 4am on monday"
• 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] Replacing singleton VM hosts will cause service interruption and discard boot-volume state

This change is replacing several standalone VM hosts rather than updating them in place. On AWS, the affected EC2 instances use root EBS volumes with DeleteOnTermination=true, and on GCP the inventory-api boot disk has auto_delete=true while its boot image changes from Debian bookworm v20260609 to v20260714. That means the existing boot volumes will be deleted with the old instances and new hosts will come up from fresh images, so any host-local packages, files, or runtime state on the root filesystem will be lost.

The replacement also cuts through live traffic paths. 540044833068.eu-west-2.ec2-instance.i-0bf4039822e01f430 is currently the only healthy target in api-207c90ee-tg, and 540044833068.eu-west-2.ec2-instance.i-0cff13d553da3fe3a is the healthy IP target behind txn-feed-terraform-example and the current holder of Elastic IP 13.134.236.98. Replacing those instances will temporarily remove the only registered backends and force EIP/target reattachment, causing request failures during the rebuild window while also recreating their root disks from scratch.
_{View reasoning tree here.}

Caution

[High Risk] Instance replacements will break consumers bound to ephemeral private IPs and stale IP-target registrations

This change replaces several standalone VM instances whose network identity is not pinned. The AWS replacements for i-0cff13d553da3fe3a, i-066a99f921bb9d0ce, i-0bf4039822e01f430, and i-07f8673d7f075bf4b all drop concrete values for private_ip, private_dns, public_ip, and primary_network_interface_id to provider-assigned values, and the current instances use auto-created primary ENIs with DeleteOnTermination=true. The GCP inventory-api instance is also being recreated with network_ip left empty, so its current 10.10.0.2 address will not be retained.

When Terraform replaces these instances, the old ENIs and instance-bound private IP/DNS identities will disappear and new ones will be assigned. Anything calling the raw private endpoints 10.10.0.2, 10.50.101.95, 10.0.101.82, 10.0.101.252, or 10.0.101.34, or using the matching ip-...compute.internal names, will lose connectivity or start pointing at dead addresses. The most concrete failure is the txn-feed-terraform-example NLB target group, which currently registers the literal IP 10.0.101.34; that target will go stale during the core-api replacement until the attachment is recreated with the new IP. The public EIP 13.134.236.98 is planned to be re-associated, so it is more stable than the private endpoints, but there will still be a cutover gap while the old instance is destroyed and the EIP is remapped.
_{View reasoning tree here.}

Caution

[High Risk] Single registered ALB and NLB backends will be deregistered during EC2 replacement, causing temporary service outage

The change replaces the only registered backends behind both AWS load balancers. 540044833068.eu-west-2.elbv2-target-group.api-207c90ee-tg currently has a single healthy instance target, i-0bf4039822e01f430, and 540044833068.eu-west-2.elbv2-target-group.txn-feed-terraform-example currently has a single healthy IP target, 10.0.101.34. Those backing EC2 instances are being replaced because their ami values change, and the corresponding aws_lb_target_group_attachment resources are also replaced, so the old targets will be deregistered and new identities registered during apply.

Because there is no second healthy target in either group, traffic will stop while the replacement instance boots and waits through target-group health checks. The ALB path will be unavailable until the new instance serves /health with HTTP 200 on port 80, and the NLB path will be unavailable until the new backend is reachable on TCP 9090. CloudWatch and GCP alert policies are being repointed to new instance IDs, so they should recover after apply, but there will still be a temporary blind spot while the old instances disappear and the new ones have not yet produced healthy metrics.
_{View reasoning tree here.}

Signals

Routine → Multiple compute resources showing unusual routine changes at 1 event/week for the last 2-5 months, while related subscriptions and alarms also changed only 1-2 events/week for the last 4-5 months.

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