Consul WebUI have issues when loading both ARM64 and AMD64 bundle

#### Overview of the Issue

When having an autoscaling group that is configured to use both ARM64 and AMD64 nodes, consul WebUI can load bundles from different instances types, and this prevent the UI from loading correctly, as bundles are not named the same between architectures.

---

#### Reproduction Steps

1. Set up an autoscaling group containing multiples processor architectures
2. Install consul on each
3. Use a load balancer in front of the autoscaling
4. Depending on your architecture mix, you may need to refresh the page multiple time for the issue to appear.

### Consul info for both Client and Server

Client info

```
Output from client 'consul info' command here
```

```
Client agent HCL config
```

Server info

```
gent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease =
revision = 98cb473c
version = 1.18.1
version_metadata =
consul:
acl = enabled
bootstrap = false
known_datacenters = 1
leader = false
leader_addr = REDACTED:8300
server = true
raft:
applied_index = 1154473
commit_index = 1154473
fsm_pending = 0
last_contact = 59.436445ms
last_log_index = 1154473
last_log_term = 26
last_snapshot_index = 1147419
last_snapshot_term = 26
latest_configuration = [REDACTED]
latest_configuration_index = 0
num_peers = 2
protocol_version = 3
protocol_version_max = 3
protocol_version_min = 0
snapshot_version_max = 1
snapshot_version_min = 0
state = Follower
term = 26
runtime:
arch = amd64
cpu_count = 2
goroutines = 519
max_procs = 2
os = linux
version = go1.21.8
serf_lan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 25
failed = 0
health_score = 0
intent_queue = 0
left = 1
member_time = 214133
members = 15
query_queue = 0
query_time = 1
serf_wan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 1
failed = 0
health_score = 0
intent_queue = 0
left = 1
member_time = 62897
members = 4
query_queue = 0
query_time = 1
```

```
server = true

bind_addr = "{{ GetInterfaceIP \"ens5\" }}"
advertise_addr = "{{ GetInterfaceIP \"ens5\" }}"
client_addr = "0.0.0.0"

data_dir = "/opt/consul"

bootstrap_expect = 3

encrypt = "REDACTED"
encrypt_verify_incoming = true
encrypt_verify_outgoing = true

leave_on_terminate = true

acl = {
enabled = true
default_policy = "deny"
down_policy = "extend-cache"
enable_token_persistence = true
}

connect {
enabled = true
ca_provider = "consul"
}

ports = {
http = 8500 # TCP only
https = 8501 # TCP only
grpc = 8502 # TCP only
grpc_tls = 8503 # TCP only
dns = 8600 # TCP and UDP
server = 8300 # TCP only
serf_lan = 8301 # TCP and UDP
serf_wan = 8302 # TCP and UDP
}

node_name = REDACTED
datacenter = "ops"
primary_datacenter = "ops"

retry_join = [REDACTED]

node_meta {
instance_purpose = "consul"
ami_id = "REDACTED"
instance_type = "t3.small"
availability_zone = "eu-west-3b"
}

autopilot = {
max_trailing_logs = 250
cleanup_dead_servers = true
last_contact_threshold = "200ms"
server_stabilization_time = "10s"
}

telemetry = {
disable_hostname = true
prometheus_retention_time = "60s"
}

ui_config = {
enabled = true
}

auto_encrypt = {
allow_tls = true
}

peering = {
enabled = true
}

tls {
defaults {
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true
ca_file = "/opt/consul/tls/consul-ca.pem"
key_file = "/opt/consul/tls/consul-key.pem"
cert_file = "/opt/consul/tls/consul-cert.pem"
}

https {
verify_incoming = false
}
}
```

### Operating system and Environment details

Server 1:
OS: Amazon Linux 2023
Architecture: x86_64

Server 2:
OS: Amazon Linux 2023
Architecture: AMD64

### Log Fragments

Not applicable

No source files or tests are identified in the issue. Start by reproducing the WebUI failure with a load balancer across ARM64 and AMD64 Consul instances, then trace how the UI bundles are loaded and named. Done means the WebUI loads reliably across both architectures without repeated refreshes.

Written by the indexing model from the issue text.