dnsproxy sets the DNSSEC OK (DO) bit on upstream queries even when enable_dnssec is false

### 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)

Linux, AMD64 (aka x86_64)

### Installation

Other (please mention in the description)

### Setup

On one machine

### AdGuard Home version

v0.107.73

### Action

Replace the following command with the one you're calling or a
description of the failing action:

```sh
dig www.example-cname.com "@192.168.5.203"
```

### Expected result

With `enable_dnssec: false`, AGH should **not** set the `DO` bit on outbound queries to upstream servers:

_Note: AGH is hosted in a kubernetes container. Hence why the source IP shows as 10.100.1.55._

```
10.100.1.55.49366 > 192.168.5.1.53: 62872+ [1au] A? www.example-cname.com. ar: . OPT UDPsize=1232 (71)
```

### Actual result

AGH sets the `DO` bit regardless of the `enable_dnssec` setting:

```
10.100.1.55.49366 > 192.168.5.1.53: 62872+ [1au] A? www.example-cname.com. ar: . OPT UDPsize=1232 DO (71)
```

### Additional information and/or screenshots

### Disclaimer

For better formatting and ease of clarity, I passed the below details through Claude so that it is easier to read.
I've validated the info and can confirm the below details are correct.

### Description

AGH's dnsproxy sets the `DO` (DNSSEC OK) flag on all outbound queries to upstream DNS servers, even when `enable_dnssec` is explicitly set to `false` in the configuration.

This causes breakage with upstream resolvers that alter their response behavior based on the `DO` bit.

Note: AGH is setup in a Kubernetes deployment hosted in Talos OS cluster.
It uses the following image: adguard/adguardhome:v0.107.73

### Relevant config

```yaml
dns:
enable_dnssec: false
```

### Steps to reproduce

1. Set `enable_dnssec: false` in AGH config (this is also the default)
2. Configure an upstream DNS server that hosts a CNAME record pointing to an external domain.
3. Run `tcpdump -i any -n -vv port 53` on the AGH container
4. Query the CNAME domain through AGH from any client

### Impact

Some upstream DNS servers change their behavior when they see the `DO` flag. In my case, Unifi's DNS server stops performing recursive CNAME resolution when it receives a query with `DO` set — it only returns the local authoritative CNAME record (with the AA flag) without chasing the CNAME to resolve the final A/AAAA records.

This means any CNAME record pointing to an external domain fails to resolve through AGH, while querying the upstream directly (without `DO`) works correctly.

On both dig commands below, I am querying my Unifi UDM-SE to demonstrate the behavior of the `DO` flag:

**With `DO` flag (how AGH queries) — only CNAME returned:**
```sh
dig +dnssec www.example-cname.com "@192.168.5.1"

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example-cname.com. 0 IN CNAME www.example.com.
```

**Without `DO` flag (how it should query) — full answer returned:**
```sh
dig +nodnssec www.example-cname.com "@192.168.5.1"

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example-cname.com. 0 IN CNAME www.example.com.
www.example.com. 55 IN A 123.123.123.123
```

### Additional context

This issue seems to be related to #8161. The CNAME-only responses reported there are a downstream consequence of this `DO` bit behavior — the upstream returns incomplete responses because it sees the `DO` flag, and AGH passes the incomplete response through to clients.
Am pending reply on the OP's side of that issue for him to test with the `+nodnssec` flag on the dig command, but based on the symptoms, seems to be the same issue.