services\mongodb\tools\log wrote to {root}/logs/{channel}.log whatever
logging.destination said. In a container that file goes with the container at
every deploy, and no collector and no `docker logs` ever sees it, so an
application that turned the database log on to trace a problem got its records
somewhere nobody could read them.

It now builds its loggers from services\log::buildHandlers(), public for this
one caller, so a record goes to the same place whichever logger writes it:
stderr as JSON lines by default, the channel's file for "file", both for
"both". An application on "file", which gf migrate pins for a v6 upgrade,
writes the same file as before. The `logging` switch on the first
mongoDatabases entry still gates every record.

MongoLogTest pins the stderr and both wiring against the handlers, without
emitting a record, and seeds its config through seedsFrameworkConfig so the
config it replaces is put back. The README's Logging section described v6 and
now describes destination.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TuYesKhgM9AcvmEyih7div