Replace the hand-built JSON:API audience controller with jsonapi_resources

Problem/Motivation

SegmentJsonApiController assembles its JSON:API document by hand. Three consequences:

• The resource type is computed as $target_type . '--' . $entity->bundle(), bypassing the resource type repository. Any site that renames or disables a resource via jsonapi_resource_config receives a type that does not exist in its API.
• The document carries no links and no pagination. A segment resolving to 50,000 members returns 50,000 resource identifiers in a single response.
• The 403 on the raw endpoint is a bare AccessDeniedHttpException rather than a JSON:API error document, so a client parsing errors[] gets nothing useful.

Proposed resolution

Depend on JSON:API Resources — suggested and runtime-guarded like the other optional integrations — and reimplement both endpoints as ResourceBase plugins. Resolve types through ResourceTypeRepositoryInterface.

entity_segment.audience_access remains the sole access chokepoint. Only the transport changes.

Remaining tasks

• Decide whether jsonapi_resources is a suggestion or a hard requirement of the JSON:API integration.
• Port both the raw and filtered endpoints.
• Assert the corrected type and the error document shape in tests.

User interface changes

None.

API changes

The response gains links and pagination; the 403 body changes shape. The module is alpha with no backwards-compatibility promise, so no shim is needed — note it in the release notes.

Data model changes

None.