fix(nginx): read the log level only from a bracketed tag in nginx output - #2074

GetLogLevel looked for each level name anywhere in the nginx output, so a word that only appears in the message counted as the level. A [warn] line that names a host or path containing alert, crit or error was read as that higher level, and ControlResult.IsError() (level above Warn) then reported a successful nginx -t as a failure:

nginx: [warn] conflicting server name "alertmanager.example.com" on 0.0.0.0:80, ignored
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

before   GetLogLevel = Alert (6)   IsError = true
after    GetLogLevel = Warn  (3)   IsError = false

IsError gates config saves in internal/config/transaction.go, internal/snippet, internal/stream and the managed upstream store, so with a server name like that every save was treated as a failed test. The same happens with a path such as /etc/nginx/sites-enabled/error-pages.conf in a [warn] line, and output with no level at all that mentions /var/log/nginx/error.log was read as Error.

nginx always writes the level in brackets (nginx: [emerg] ..., 2026/11/02 12:00:00 [error] ...), so the fix matches [level] instead of the bare word. It still returns the highest level found, and the existing constant tests ([debug] through [emerg], plus Unknown for untagged text) pass unchanged.

Tests: TestGetLogLevelIgnoresLevelNamesInsideTheMessage and TestControlResultIsNotErrorForWarnOutputNamingAnAlertHost fail before the change and pass after. go test -count=1 ./internal/nginx/ passes, and gofmt and go vet are clean.

AI disclosure: written with an AI coding assistant. I reproduced the misread level before the change and checked the tests fail without the fix myself.