You wouldn’t, the need to do this is normally a code smell and a warning sign that you have done something wrong, or are trying to work against react and the way blocks are intended to work in some way.
However if you wanted to continue down the path in the wrong direction, you would rely on useSelect to acquire the information you wanted, directly accessing select isn’t great and it also means you no longer get changes in your component.
But as I said, and as revealed in your comment, this is all a big hack to work around wanting to show embeds in a block, resulting in putting embed blocks in the inner blocks as children, forcing you to then implement this as a hack to get the information you need, an X Y problem. Don’t do that.
Blocks should not depend on other blocks like this, they need to be composable like actual lego bricks. It’s ok if two bricks were designed to work together, e.g. column and columns blocks, but it’s not a good idea to repurpose a block for editor UI purposes like that.
Instead, read the edit component of the core/embed block at:
https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/embed/edit.js
It shows:
- how to get a preview code and render it
- handling loading spinners for when it’s fetching the embed code
- URL input for video links
- sandboxes
- embeddable vs unembeddable items
With these the URL would just become another prop on your block.
It may even be possible to instead adjust the embed block itself with additional attributes and components via filters to extend it if the goal of your task is to provide a modified UI for an embed. However the details of what your work is intended to implement are scarce.