feat(wp-content): make the bricks_wp_* post tools work on custom post types

[floodwayprintco]

All four bricks_wp_* post tools hardcode /wp/v2/posts, which serves only the built-in post
type. Every custom post type comes back as:

Invalid post ID

on an id that /wp-json/wp/v2/<cpt>/<id> returns fine. It reads like a bad id, so you go hunting
for the id rather than for the endpoint.

On the site this came from, that blocked the writing that mattered most: 25 service-area city
pages keep their per-city copy in post_content while the shared furniture lives in a Bricks
template. The template was editable through the MCP and the copy was not.

The change

An optional post_type parameter (the REST base, default "posts") on list, get, create
and update, used in the URL:

-const posts = await wpGetStandard(`/wp/v2/posts?${params}`, { raw: true });
+const posts = await wpGetStandard(`/wp/v2/${args.post_type || 'posts'}?${params}`, { raw: true });

The default preserves existing behaviour exactly, so nothing that works today changes. 11 lines
added, 7 changed, one file.

Notes

• The REST base is discoverable rather than guessed. bricks_get_post_types already returns
  it per type, and each param description points there.
• Categories and tags are left alone. They're taxonomies, not post types, and they'd need a
  different parameter.
• Only post types with show_in_rest are reachable, which is the existing REST behaviour and not
  something this changes.

Branched off main. node --check passes on the changed file.