The alias path processor resolves aliases through a hardcoded list of one site's bundles

Problem/Motivation

MyrestAliasPathProcessor turns a front-end alias into an API path, and it does so with a switch over bundle names: page, doctor, our_cases, article, news, discount, dynamic for nodes, and category, services, branches for taxonomy terms, each mapped to a literal path such as /api/v1/get-node-doctor/{nid}. On a site whose content types are named anything else — which is every site but the one this was written for — an alias resolves to nothing and the endpoint answers 404. The bundle map added later softens the symptom for a renamed type but does not remove the list: a bundle that is not one of these ten has no case to fall into.

The scope of the processor is not the problem and should not be re-opened: processInbound() already returns immediately for any path that is not this module's own endpoint, which earlier work on this module established.

Proposed resolution

• Resolve the alias to an entity, then ask the endpoint registry which resource serves that entity type and bundle, instead of switching on the bundle name.
• Until that registry exists, derive the path from the resource plugin definitions, which already declare myrest_bundle and myrest_bundle_entity_type — the information the switch duplicates by hand.
• A bundle with no matching resource resolves to nothing and the request answers 404 as it does now, rather than falling through to a wrong endpoint.
• Take self::ENDPOINT from the configured API prefix rather than from a class constant, once the prefix becomes configurable.
• Review the priority of 900 while the file is open: with the early return in place there is no ordering reason left for it to outrank the alias processor of the core.
• Functional coverage on a bundle that is not in the current list, which is the case that fails today.

Remaining tasks

Everything. The switch is the last place in the request path where one site's content model is written into the module's code.