Do nested Livewire components inherit the parent's #[Locked] attribute or acquire independent locks?

Livewire v3 introduced the #[Locked] attribute and withoutLock() method to control request serialization per component. However, the documentation does not specify the locking behavior when a parent component marked #[Locked] renders child components via @livewire('child', key($id)).

Each nested component generates its own lock key (livewire:component:{id}:lock) based on its component ID. The parent lock is acquired in HandleComponentRequests::ensureComponentIsNotAlreadyRunning() before the parent's update cycle, but it is unclear whether the framework automatically extends that lock to cover child updates triggered during the same request, or whether each child independently attempts to acquire its own mutex.

This matters for latency and correctness: if children acquire independent locks, concurrent updates to a parent and its children can interleave, potentially causing stale reads on public properties passed down as data attributes. If the parent lock is implicitly held for the entire render tree, then a slow child update serializes all siblings and the parent, increasing tail latency.

Does a parent component's #[Locked] attribute implicitly serialize updates to nested child components, or must each child explicitly declare #[Locked] to participate in the same critical section? Which approach does the current v3 implementation take, and is the behavior guaranteed or subject to change?