`log.enabled: false` leaves the legacy logger enabled

[danieloleary]

Prerequisites

• I have checked the Wiki and Discussions and found no answer
• I have searched other issues and found no duplicates
• I want to report a bug and not ask a question or ask for help
• I have set up AdGuard Home correctly and configured clients to use it

I found this while investigating the macOS service-log behavior in #8564. I
use and really like AdGuard Home on my Mac, so I followed the logging path a
little further and noticed this separate, platform-independent regression.

I am filing it separately because it is a small bug with a small fix, and it
does not belong in the larger macOS logging change.

Plain English

AdGuard Home is moving from an older logger to a newer one. Setting
log.enabled: false correctly silences the newer logger, but the older logger
can remain switched on. The fix makes the same off switch control both.

Platform (OS and CPU architecture)

All platforms. Reproduced from a source checkout on macOS ARM64.

Installation

Source checkout of current master.

Setup

Focused logger regression test; the defect is platform-independent.

AdGuard Home version

Current master at 090f75d79fcad19a7447d158fc926a304b0dff57.

Action

Load logging settings with:

log:
  enabled: false

Then construct the configured logger. The focused unchanged-code regression
sets the transitional legacy logger to INFO, calls newSlogLogger with
Enabled: false, and checks its resulting level.

Expected result

Both the structured logger and the transitional
github.com/AdguardTeam/golibs/log logger are disabled, matching the feature
introduced for #7079. The legacy logger level should be OFF.

Actual result

newSlogLogger returns the discard structured logger before reaching the
existing log.SetLevel(log.OFF) branch. The structured logger is disabled,
but the legacy logger remains at its previous level and may continue emitting.

The unchanged-code regression produced:

expected legacy log level: OFF
actual legacy log level: INFO

Additional information and/or screenshots

I have a two-line fix ready that moves log.SetLevel(log.OFF) into the disabled
early-return path and removes the unreachable duplicate condition. It is
isolated on a one-commit branch with a changelog entry and regression test.

Proof after the fix:

go test -race ./internal/home -run '^TestNewSlogLoggerDisabled$' -count=20

The focused test passed 20 consecutive runs, and the full make go-check
suite passed. This change is intentionally separate from the proposed macOS
service-logging enhancement.