fix(logs): avoid false-positive error level for no-error values (#4538)

[brendler]

What

getLogType classifies log lines purely by keyword/substring matching, with no awareness of the value following a keyword. As a result, successful job-scheduler completion lines such as:

▶ NOTICE Finished job "nightly-task" in "1.2s", failed: false, skipped: false, error: none

get highlighted red as errors, because error: none matches the error: pattern and failed: false matches the failed pattern.

Closes #4538.

Changes

• error: / err:, failed, and failure now only classify as an error when not immediately followed by a no-error value (none|null|false|nil|no|0), via negative lookahead. This is value-specific, not a blanket suppressor — a line like error: none, failed: true is still correctly flagged as an error.
• Bare NOTICE (no colon) is now treated as info so scheduler lines short-circuit before the error branch. notice: (with colon) is left to the warning branch, preserving existing behaviour.

Tests

Added __test__/utils/log-type.test.ts covering the scheduler "finished" line, error: none, the mixed error: none, failed: true case (proves the exclusion isn't over-broad), genuine errors, and bare NOTICE. All pass.

Note

This is a targeted fix for the reported false positives. The underlying heuristic is still substring-based and has produced similar issues before (see closed #3305); a structured log-level parser would be the more robust long-term solution, but is out of scope here.