Log time until next MTORR broadcast for source routing

[TheJulianJES]

AI summary

setSourceRouteDiscoveryMode returns a uint32_t remainingTime — the milliseconds until the next MTORR broadcast — but bellows was discarding it. Capture and log it at debug level. With the RESCHEDULE mode this is approximately the configured min-interval; the value makes startup behavior visible in logs and matches what zigbee-herdsman's ember adapter reports
("Started source route discovery. Xms until next broadcast.").

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.54%. Comparing base (4b97a6d) to head (667f5b5).

Additional details and impacted files

@@           Coverage Diff           @@
##              dev     #717   +/-   ##
=======================================
  Coverage   99.54%   99.54%           
=======================================
  Files          61       61           
  Lines        4147     4148    +1     
=======================================
+ Hits         4128     4129    +1     
  Misses         19       19           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zigpy-review-bot]

Logging-only change, looks correct and complete. Verified against the EZSP frame definitions and zigbee-herdsman's equivalent log.

Return-value type / units

The frame is already declared with remainingTime: t.uint32_t in bellows/ezsp/v8/commands.py (line 47-48) and inherits unchanged through v9-v18, so no frame-definition changes are needed. Silicon Labs' public SDK docs (Source Route 8h, v8.0.2) only say the return is uint32_t and don't explicitly state the unit, but zigbee-herdsman treats and logs it as ms (emberAdapter.ts: `Started source route discovery. ${remainTilMTORR}ms until next broadcast.`) and that's consistent with the typical observed values (~1000-3600000 with default MTORR intervals). The PR's %d ms label is correct.

Complementarity with #716

This is most informative once #716 lands and bellows passes RESCHEDULE; with the current ON-only mode the value is the time until the next periodic broadcast (effectively MTOR_MIN_INTERVAL after the previous tick, or up-to-MTOR_MAX_INTERVAL from boot since no immediate broadcast is fired). Worth noting in the PR body but not a blocker for this one — the log is useful on its own.

Minor nits (non-blocking)

• herdsman logs this at info; bellows uses debug. Either is defensible (info shows up once per startup, debug keeps default logs quieter); calling out so you can pick consciously.
• No test asserts the log line itself, only that the new return-value tuple is consumed without error. Fine for a logging-only PR.
• Tuple-unpacking the single return as (remaining_ms,) = await ... is consistent with how the rest of bellows/ezsp/__init__.py handles single-element EZSP returns, so no style concern.

Tests pass locally (tests/test_ezsp.py 80/80) against 667f5b5.