(Some) of bootstrap_dns servers being down can affect use of DoT DNS servers configured as upstream/fallback

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) and found no answer

- [x] I have searched other issues and found no duplicates

- [x] I want to report a bug and not [ask a question or ask for help](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a)

- [x] I have set up AdGuard Home correctly and [configured clients to use it](https://github.com/AdguardTeam/AdGuardHome/wiki/Clients). (Use the [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions/categories/q-a) for help with installing and configuring clients.)

### Platform (OS and CPU architecture)

Darwin (aka macOS), AMD64 (aka x86_64)

### Installation

Custom package (OpenWrt, HomeAssistant, etc; please mention in the description)

### Setup

On a router, DHCP is handled by the router

### AdGuard Home version

0.107.63

### Action

Today 1.1.1.1 and 1.0.0.1 (and associated DoT) servers went down. I figured its a good time to adjust configuration to make use of the fallback DNS servers, but the DNS resolving would still fail to work:

```
#resolvectl query google.com
google.com: resolve call failed: Could not resolve 'google.com', server or network returned error: SERVFAIL
```

after my relevant configuration was adjusted to read as such:

```diff
dns:
upstream_dns:
- tls://one.one.one.one
upstream_dns_file: ""
bootstrap_dns:
- 1.1.1.1
- 1.0.0.1
+ - 9.9.9.9
+ - 149.112.112.112
+ - 8.8.8.8
fallback_dns:
+ - tls://dns.quad9.net
+ - tls://dns.google
upstream_mode: parallel
fastest_timeout: 1s
upstream_timeout: 10s
```

### Expected result

I had hoped that AGH would:

1. Try the bunch of `bootstrap_dns` servers in quick succession/parallel to resolve `one.one.one.one`;
2. Notice that `one.one.one.one` (resolved to `1.1.1.1`/`1.0.0.1` via one of the working `bootstrap_dns` servers) is down (after `upstream_timeout`);
3. Try the bunch of `bootstrap_dns` servers in quick succession/parallel to resolve `dns.quad9.net`;
4. Use `tls://dns.quad9.net`.

### Actual result

A bunch of

```
2025/07/15 01:19:34.061921 ERROR response received addr=1.1.1.1:53 proto=udp status="exchanging with 1.1.1.1:53 over udp: read udp yesitsme:56372->1.1.1.1:53: i/o timeout"
2025/07/15 01:19:34.061967 ERROR response received addr=1.0.0.1:53 proto=udp status="exchanging with 1.0.0.1:53 over udp: read udp yesitsme:50545->1.0.0.1:53: i/o timeout"
2025/07/15 01:19:34.061969 ERROR response received addr=1.1.1.1:53 proto=udp status="exchanging with 1.1.1.1:53 over udp: read udp yesitsme:48662->1.1.1.1:53: i/o timeout"
```

in the logs and resolution still failed

```
#resolvectl query google.com
google.com: resolve call failed: Could not resolve 'google.com', server or network returned error: SERVFAIL
```

I had to remove both `1.1.1.1` and `1.0.0.1` from the list of `bootstrap_dns` in order to recover DNS resolution. Only then I would see attempting AGH to connect to the faulty `upstream_dns`:

```
2025/07/15 01:19:57.318565 ERROR response received addr=tls://one.one.one.one:853 proto=tcp status="reading response from tls://one.one.one.one:853: read tcp yesitsme:42960->1.0.0.1:853: i/o timeout"
```

at which point it finally fell back onto fallback DNS server and started resolving DNS queries.

### Additional information and/or screenshots

https://news.ycombinator.com/item?id=44565836
https://www.cloudflarestatus.com/incidents/28r0vbbxsh8f

I didn't actually spend time to look at network packet traces to figure out how AGH operates. I can imagine my conclusions to be factually incorrect. I can only claim that things were not working until I removed `1.1.1.1` and `1.0.0.1` from `bootstrap_dns` list even after I waited for ~5 minutes after applying the new configuration.