Testing: Add functional coverage per resource group

Problem/Motivation

Issue 54 covered what every resource of the module shares - the access myrest api gate and the response shape of one resource that needs no content. What each group actually returns is still untested: node resources, taxonomy term resources, the form submission resources, the search-backed listings and the paginated lists. These are the parts a refactoring is most likely to break, and the reason the earlier ones were left out is that they need content fixtures rather than a reason of principle.

Proposed resolution

• Build reusable fixtures: the node types, vocabularies and fields the resources read, created from the module's own bundle and field mappings rather than hard-coded names.
• Cover one resource per group end to end - status code, response shape and the cache metadata it declares - and the shared list behaviour (paging, max_page_size, sort parameters) once, on the list base.
• Cover the error envelope of errorResponse(): the status code, error, error_message and error_code keys.
• Add the search-backed resources behind a check for search_api, so the suite still runs where the optional integration is absent.
• Set a coverage threshold and enforce it in the pipeline once issue 66 exists.
• Add the aggregate rating queries of MyrestReviewsAggregator here. Issue 64 could not cover them: they need the review content type and field_review_rating, which is the fixture work this issue is for.

Remaining tasks

Build the fixtures, then implement the suites group by group.

User interface changes

None.

API changes

None.