The inbound path processor still matches the API prefix it was written against

Problem/Motivation

The prefix the API is mounted on is configurable, so that this module can be installed beside a REST layer a site already has. One place did not follow: the inbound path processor decides whether a request is the endpoint it exists for by comparing the path against a constant that spells the old default, /api/v1/get-path-by-alias.

On a site that moved the prefix, that endpoint is routed and answers - the resource itself moved with the rest - but it is never processed. The alias is not resolved onto the endpoint that serves the entity behind it, the redirect the front end reads is not set, and the rules that answer 404 for a request carrying the prefix of the default language never run. Nothing errors; the endpoint simply answers the wrong thing, which is the worst shape a configuration bug can take.

Proposed resolution

• Build the endpoint path from the configured prefix, read from the service every other part of the module reads it from, rather than from a constant.
• Keep the constant as what it should have been - the endpoint relative to the prefix - so the name of the endpoint still lives in one place.
• Cover it with a kernel test that moves the prefix and asserts the alias still resolves onto the endpoint of the entity, next to the tests that already assert the scope of this processor.
• Check the same question of everything else that holds a path: a literal that survived the setting is a bug of the same kind, whether or not anybody has hit it yet.

Remaining tasks

Everything.