Boot order ≠ dependency order.
A static supervisor starts its children in list order, one at a time. A child's
init/1 runs before the next sibling is started — so if child A synchronously
calls a sibling that appears later in the list, that sibling isn't alive yet
when A initialises. On first boot A's init blocks until it times out, then
crashes; the supervisor retries in the same order and crash-loops.
This is invisible to the supervision tree (the tree says both are contained
siblings) and easy to introduce by reordering children. We flag it by combining
two facts Firebreak already has: the child order (exact from init/1 where
available) and the in_init? coupling edges (static).
DynamicSupervisor children have no static start order, so this check applies
only to Supervisor and Application roots.
Summary
Functions
@spec analyze([Firebreak.ModuleInfo.t()]) :: [Firebreak.Finding.t()]