core/memory_lifecycle_watchdog library

Classes

DisposedWatchdogEntry: A WatchdogEntry that was properly released, kept in a short bounded history for debugging ("did X actually get disposed, and when") — separate from MemoryWatchdog.orphans, which only ever looks at still-live entries.
MemoryWatchdog: Debug-only tracker for disposable resources (tickers, controllers, overlay entries, stream subscriptions, Flame components) that are easy to forget to dispose — a widget/service calls track when it CREATES one and release when it properly disposes it; anything still tracked when orphans is called (typically at the end of a test, or from a debug overlay/health report during a real session) is a leak candidate.
WatchdogEntry: One still-live tracked resource — owner is free text (typically a runtimeType.toString() or a widget's debug label), not a live reference to the resource itself: this class never holds the actual Ticker/AnimationController/etc, only metadata about it, so tracking something can never itself keep it alive or leak it further.

WatchdogKind: What kind of disposable resource a WatchdogEntry tracks — the 5 categories this task's own user story names (ticker/controller/ overlay/subscription/Flame component); custom covers anything else a consumer app wants to track through the same mechanism.

memoryWatchdogHealthCollector() → HealthCollectorSpec: Opt-in SdkHealthReport (FEAT-39) section reporting the current orphan count/kinds — a consumer app registers this itself (report ..register(memoryWatchdogHealthCollector())), it's not part of defaultHealthCollectors() since, unlike audio/performance/ remoteConfig, this isn't a runtime module a consumer "has registered or not" — it's always available, opt-in by nature of being a debug diagnostic.