fix(logger): puppeteerLogger should check DEBUG before checking --log-file

[mittalpk]

Fixes #2731.

Problem

Since v1.8.0 (#2562, replacing the debug npm package with Node's native util.debuglog), puppeteerLogger() in src/utils/logger.ts checks logFileStream truthiness before checking whether the namespace is DEBUG-enabled:

export const puppeteerLogger = (prefix: string) => {
  if (logFileStream) {
    return (...args) => { logFileStream!.write(...); };  // unconditional
  }
  const dbg = util.debuglog(prefix);
  return dbg.enabled ? (...) => dbg(...) : undefined;      // gated
};

So once --log-file is set, every puppeteer:protocol:SEND/RECV message (full CDP JSON payloads — network events, accessibility trees, etc.) gets written to the log file regardless of DEBUG, producing GB-scale log files instead of the KB-scale v1.7.0 behavior for the same traffic.

In v1.7.0, saveLogsToFile() called debug.enable() with the user's DEBUG namespaces plus mcp:log, so only explicitly-enabled namespaces were ever written — mcp:log always (since it was always added to the enabled set), everything else only if the user opted in.

Fix

Reordered puppeteerLogger to check dbg.enabled first, so both the file-writing and util.debuglog-writing branches are gated the same way — matching v1.7.0 semantics. logger() (the separate function backing the always-on mcp:log namespace) is untouched; its unconditional file-write is correct, not a bug — mcp:log was always in the enabled set even in v1.7.0.

How did you test it

Added tests/utils/logger.test.ts + a tests/utils/fixtures/puppeteer-logger-fixture.ts helper. util.debuglog(...).enabled reflects NODE_DEBUG as of process start, not a value togglable at runtime, so the fixture is spawned as a fresh child process per case (4 cases: namespace disabled + log file → file stays empty; namespace enabled + log file → file gets the message; NODE_DEBUG=* + log file → file gets the message; namespace disabled + no log file → returns undefined, matching existing behavior).

Verified fail-before/pass-after by running the equivalent logic directly against both the pre-fix and post-fix source (via git stash) — pre-fix, the "disabled + log file" case wrongly writes to the file; post-fix, it doesn't.

eslint and prettier --check both clean on all 3 changed/added files. I was not able to run the full npm test (tsc && node scripts/post-build.ts needs the third_party/devtools-frontend git submodule, which failed to fetch in my environment — appears to be a shallow-submodule/pinned-commit mismatch, unrelated to this change) or the full project tsc (blocked by the same missing submodule via src/third_party/index.ts's import of it). I isolated my 3 changed files with a standalone tsc --noEmit invocation instead — confirmed zero type errors originate from any of them (the errors present in that run are 100% pre-existing, from unrelated puppeteer-core/rxjs/submodule type declarations, and disappear if those files are excluded). Happy to re-verify against a full build if a maintainer can point me at a working submodule fetch, or if this is a known environment quirk.

[Lightning00Blade]

Thank for the PR but there are simpler ways to test this. Please refer to #2743