Description and testing instructions from trac ticket:

Fixes trac ticket: https://core.trac.wordpress.org/ticket/53508. When back ported.

When inserting a Query Loop, the ability to edit posts inside of it was removed in [51101] due to a confusing user experience relating to this.
If turns out the Query Loop block still lets you edit post content, but only once. If after adding a Query Loop block, you either reload the editor page, or if the user makes an edit to the post content inside the loop and saves it, the content is locked from future editing.
This means that a user can make edits to the posts shown in the loop right after adding the block.
Steps to reproduce:

1. Create a new page
2. Insert "Query Loop" block
3. Click inside title of the displayed post (for example "Hello world!" being the example post shipped with WordPress)
4. The "Update" button in the editor now lets you update the page you are in, and your third party block.

Note

It might be easier to reproduce when clicking the grid view of Query Loop patterns when inserting. Since it's a race condition between posts and queryId, you have to select a pattern that shows the Image Placeholder (in Featured Image) that looks like allowing the upload (which it does)

What was the problem

Query Loop needs a unique id to handle multiple pagination properly and is using queryId attribute. This attribute is set on insertion/creation of the block after the first rendering.

This has caused some race conditions with the check we had for making Post blocks not editable inside this block, which used the existence of queryId. This PR adds the queryId as a dependency to our memoized block contexts so as to always be provided down the chain.