Query block with multiple post types never renders in the editor (comma-joined postType is not a resolvable entity)

### Description of the bug

When a Curatable Query selects **more than one post type** and its template is a `core/post-template`, the block never renders in the editor — it shows an empty dashed placeholder with a spinner indefinitely. The front end renders correctly.

The cause is that `blocks/query/edit.tsx` writes the selected post types into `query.postType` as a comma-joined string:

```js
const postTypeString = postTypes.join(',');
…
setAttributes({ query: { perPage: numberOfPosts - postBlockCount, postType: postTypeString }, queryId: 0 });
```

`core/post-template` hands that value to core-data as a single post type. A comma-joined string is not a registered entity, so the request is never issued at all. Measured in the editor console on an affected page:

```js
wp.data.select('core').getEntityConfig('postType', 'post,cpt_one,cpt_two') // null
wp.data.select('core').getEntityConfig('postType', 'post') // defined
wp.data.select('core').getEntityConfig('postType', 'cpt_one') // defined

wp.data.select('core').getEntityRecords('postType', 'post,cpt_one,cpt_two', { per_page: 3, include: [99, 98, 97] }) // null
wp.data.select('core').hasFinishedResolution('getEntityRecords', […same args…]) // false
wp.data.select('core').isResolving('getEntityRecords', […same args…]) // false
```

`isResolving` and `hasFinishedResolution` are **both** false — core-data cannot resolve an unregistered entity, so `core/post-template` waits on a request that never starts.

Everything upstream of that is healthy, which is what makes it confusing to diagnose:

- `wp-curate/v1/posts` returns the correct mixed-type IDs quickly (`200` in ~0.45s, 19 ids across the three types).
- `backfillPosts` is populated correctly on the block.
- `/wp/v2/search?include=` resolves each custom post type fine, so `usePostById` would work.
- The parsed block tree is valid; no invalid blocks, no console errors.

The block attributes at the point of failure:

```json
{
"numberOfPosts": 3,
"postTypes": ["post", "cpt_one", "cpt_two"],
"posts": [null, null, null],
"backfillPosts": [99, 98, 97, 96, 95, "…19 total"],
"query": {
"perPage": 3,
"postType": "post,cpt_one,cpt_two",
"type": "post,cpt_one,cpt_two",
"include": "99,98,97",
"orderby": "include"
}
}
```

### Steps To Reproduce

1. Register two or more post types with `show_in_rest`.
2. Insert a Curatable Query whose template is a `core/post-template` wrapping a `wp-curate/post`.
3. In Query Parameters, select **two or more** post types.
4. The block shows a spinner and never renders. With a single post type selected it renders immediately.

### Additional Information

Version: **3.2.3** (latest at time of writing). WordPress 7.0.2, PHP 8.4.

Because the editor preview never resolves, the per-slot **Pin a Post** buttons never render either, so multi-type queries cannot be curated at all through the UI — the pinning feature is effectively unavailable in exactly the case editors most want it.

Not a duplicate of the two closest issues, though related:

- **#445** fixed `postType` propagation for the path *without* `core/post-template`. This is the complementary case — *with* the template block.
- **#237** covered pinning non-`post` types. Related note: `updateValidPosts` still queries `/wp/v2/posts` with `type: postTypeString`, and `/wp/v2/posts` only ever returns the `post` type, so `validPosts` looks like it would come back empty for pinned items of other types. Not verified — flagging in case it is the same root assumption.

Possible directions, in case they are useful:

- Pass a resolvable post type to the template's query (for example the first selected type, or `postTypes[0]`) while keeping the multi-type query for the server render, so the preview resolves even if it under-represents the mix.
- Or bypass `core/post-template` for multi-type queries and render `postBlockCount` explicit `wp-curate/post` children, which resolve per post via `usePostById` and already handle mixed types correctly after #445.

Happy to open a PR if you have a preference on the approach.