Apply [logging] log_level to the meshcore library logger too

[sg]

Problem

Setting log_level = DEBUG in mcbot.conf had no apparent effect — the only way to get debug logging was the --debug CLI flag.

Root cause

The bot uses two loggers: mcbot (its own) and meshcore (the library's verbose packet/protocol logs). In setup_logging:

• [logging] log_level was applied only to the mcbot logger.
• --debug set only the meshcore library logger to DEBUG; otherwise it was pinned to INFO.

Most of the output people think of as "debug logging" comes from the library logger, so log_level=DEBUG raised only the mcbot logger and looked like a no-op, while --debug lit up the library logger. Confirmed:

log_level=DEBUG, no --debug -> (mcbot=DEBUG, meshcore=INFO)
log_level=INFO,  --debug    -> (mcbot=INFO,  meshcore=DEBUG)

Fix

setup_logging now computes one effective level and applies it to both loggers, with --debug as a shortcut for DEBUG:

level = "DEBUG" if cfg.debug else cfg.log_level.upper()
bot_log = _reset("mcbot", level)
mc_log  = _reset("meshcore", level)

Result:

• log_level=DEBUG → both DEBUG (full debug, incl. library output) — equivalent to --debug
• log_level=INFO (default) → both INFO (unchanged)
• log_level=WARNING → both WARNING (the library is now quietable too, which it wasn't before)
• --debug → both DEBUG regardless of log_level

Minor behavior note: --debug now also raises the bot's own logger to DEBUG (previously it touched only the library) — intuitive, since "debug" should mean full debug.

Changes

• mcbot.py — unify the level across both loggers in setup_logging.
• mcbot.conf.example — document that log_level covers both loggers and that DEBUG equals --debug.
• tests/test_logging.py — 4 checks asserting both loggers track log_level and --debug.

Testing

tests/test_logging.py passes (4/4); existing test_repeat_tracking.py and test_radio_eviction.py still pass; py_compile clean.

🤖 Generated with Claude Code