Add a legacy host setting

[JackLewis-digirati]

What does this change?

Resolves #654

Adds the ability to set a legacy hostname that is used for the conversion from https://presentation-api.* to https://iiif.*

The code also contains a cutoff date. If the manifest was created before the cutoff point, then paths will still be generated in the legacy format.

Configuration Changes

Note

This PR introduces configuration changes.

Service	AppSetting	Required?	Description	Default
API, BackgroundHandler	PathSettings:LegacyPresentationApiUrl	N	A legacy host name used for matching paths in the body that haven't been updated to the new subdomain, and generating paths on the legacy hostname	null
API, BackgroundHandler	PathSettings:LegacyHostnameCutoffDate	N	A cutoff point for when the legacy hostname should be used in generated paths.	null

[JackLewis-digirati]

How this works

Implements #654 / ADR 0004 - lets us move the default presentation host from presentation-api.* to iiif.* without breaking ids on resources that already exist.

New settings (PathSettings)

• LegacyPresentationApiUrl (optional) - the old default host, e.g. presentation-api.*.
• LegacyHostnameCutoffDate (optional) - the date/time the new default host went live. Both are null unless explicitly configured, so a deployment that's never had a legacy hostname doesn't need to set anything.

Outgoing (id generation) - PathSettings.GetPresentationUrl(customerId, created)

When generating an id, the host is chosen with this precedence:

1. CustomerPresentationApiUrl[customerId] override, if set - always wins regardless of date.
2. LegacyPresentationApiUrl, if configured and the resource's Created date is before LegacyHostnameCutoffDate.
3. PresentationApiUrl (the new default) - otherwise, including when created is null or legacy isn't configured.

Created is threaded through from PathGeneratorBase for the resource types whose ids can be minted on either host (Collection, Manifest, CanvasPainting) - see the new Created param on IPresentationPathGenerator. One deliberate consequence: if an old resource is deleted and recreated, it gets a fresh Created and lands on the new default host, not the legacy one - matches the caution note on the issue.

Note HostnameDrivenPresentationPathGenerator (API) - which mirrors whatever host the live request came in on rather than looking anything up - takes the new created param for interface parity but deliberately ignores it, since that mechanism is calling-URL-based, not creation-date-based (see ADR's "top-level ids rewritten... based on the calling URL" behaviour).

Incoming (recognising a request's host) - PathSettings.IsCustomerRecognisedHost

Extended to accept three hosts per customer instead of two: their CustomerPresentationApiUrl override (if any), the shared LegacyPresentationApiUrl, and the shared PresentationApiUrl. This is what the ADR calls out as the required code change - it's what's used to decide whether to deserialize URLs found in a request body.

Where it's wired

Both API and BackgroundHandler bind PathSettings via RegisterSharedServiceSettings(). BackgroundHandler uses the config/cutoff-driven SettingsDrivenPresentationConfigGenerator directly as its IPresentationPathGenerator (no live request to mirror there); API uses HostnameDrivenPresentationPathGenerator for request-mirrored behaviour but also registers SettingsDrivenPresentationConfigGenerator for the cutoff-driven id-generation path.

Infra-side work from the ADR (redirects, CloudFront forwarding, per-environment rollout) is out of scope here - this PR is just the config-driven host selection piece.