Use MillisInternal in the scope and say setup() is not timed by the guard

esphome/core/application.h

@@ -647,8 +647,8 @@ class LoopBlockingGuard {
 /// bug instead of fixing it. If in doubt, leave the warning in.
 ///
 /// Only work timed by a LoopBlockingGuard is affected, that is a component's
-/// loop() or a scheduler callback; setup() is not timed, so the scope does
-/// nothing there. Main loop task only. The watchdog is not fed inside the
+/// loop() or a scheduler callback; setup() is not timed by the guard, so the
+/// scope has no effect on the warning there. Main loop task only. The watchdog is not fed inside the
 /// scope, so the work must finish within the watchdog timeout, or be paired
 /// with a watchdog::WatchdogManager that raises the timeout for the same
 /// stretch. Scopes may nest; the outermost one decides how much of the pass
@@ -664,12 +664,12 @@ class LoopBlockingGuard {
 ///   }
 class UnavoidableBlockingScope {
  public:
-  UnavoidableBlockingScope() : started_(millis()), pass_start_(App.get_loop_component_start_time()) {}
+  UnavoidableBlockingScope() : started_(MillisInternal::get()), pass_start_(App.get_loop_component_start_time()) {}
   ~UnavoidableBlockingScope() {
     // Move the pass start seen at entry forward by the time spent here, so an
     // outer scope overrides an inner one instead of adding to it; never past
     // now, which would underflow the guard's subtraction
-    const uint32_t now = millis();
+    const uint32_t now = MillisInternal::get();
     const uint32_t moved = this->pass_start_ + (now - this->started_);
     App.set_loop_component_start_time_(static_cast<int32_t>(now - moved) < 0 ? now : moved);
   }

esphome/core/millis_internal.h

@@ -51,6 +51,7 @@ class MillisInternal {
   }
   friend class Application;
   friend class LoopBlockingGuard;
+  friend class UnavoidableBlockingScope;
 };
 
 }  // namespace esphome