v1.8.1 regression: High CPU usage on ARM graviton servers

#### Overview of the Issue

Since 1.8.1 release, creating a AMI is consuming a lot of CPU. We are using packer with ansible plugin, packer binary, packer-plugin-ansible are consuming from 2 to 3% CPU which is quite consistent across versions.
But since 1.8.1 `packer-plugin-amazon` is eating our 2 vCPU available in our intances.

Using same packer recipe but pinning amazon plugin to 1.8.0 is working with no issue. In this case `packer-plugin-amazon` is using from 2 to 3% CPU available.

#### Reproduction Steps

Just run any `packer` build on AWS ARM graviton instance.
CPU usage will be 100% as soon as the `packer-plugin-amazon` is spawned.

### Plugin and Packer version

`Packer v1.15.3`
`packer-plugin-ansible v1.1.4`
`packer-plugin-amazon v1.8.1`

### Simplified Packer Buildfile

```
packer {
required_plugins {
ansible = {
version = "~> 1"
source = "github.com/hashicorp/ansible"
}
amazon = {
source = "github.com/hashicorp/amazon"
version = "~> 1"
}
}
}

source "amazon-ebs" "mysource" {
region = var.region
subnet_id = var.subnet_id
source_ami_filter {
filters = {
name = "debian-12*"
root-device-type = "ebs"
architecture = "x86_64"
}
owners = ["amazon"]
most_recent = true
}
instance_type = "t3a.small"
ssh_username = "admin"
ami_name = "mybuild"
launch_block_device_mappings {
device_name = "/dev/xvda"
volume_size = 20
volume_type = "gp3"
delete_on_termination = true
}
tags = {
Name = "mybuild"
}
}

build {
name = "mybuild"
sources = ["source.amazon-ebs.mysource"]

provisioner "ansible" {
user = "admin"
playbook_file = "./ansible/playbooks/base.yml" # Add any playbook here
}
}
```

### Operating system and Environment details

The instance running packer is AWS ARM Graviton instance `t4g.micro` with 2 vCPU and 2G of RAM.
The target instance/AMI can be whatever architecture/size, issue is happening on the instance actually running packer.

### Log Fragments and crash.log files

No error seen anywhere, just CPU usage which is very high.
Packer is actually running but so slow because of CPU starvation that it takes too long for us to see it finish.
But we can see it is actually running as logs are filling very slowly (compared to cases with plenty of free CPU).