Replace caller-supplied Didomi geo headers with trusted platform geo

[prk-Jr]

Description

The Didomi proxy currently copies inbound FastlyGeo-CountryCode and FastlyGeo-Region headers into X-Geo-Country, X-Geo-Region, and CloudFront-Viewer-Country for SDK requests that do not carry the authoritative loader geo introduced by #85.

In the Compute request path, these values are ordinary inbound headers and are not populated by Trusted Server. A caller can therefore provide them. Because Didomi SDK responses retain upstream cacheability, a geo-dependent response could be seeded under a URL that does not identify that geography.

This behavior predates PR #1127. That PR replaces the headers with trusted RuntimeServices.geo() values for canonical notice-loader requests, but deliberately preserves legacy behavior for other SDK paths and when geo_query_parameters is disabled.

Reproduction steps

1. Enable the Didomi integration.
2. Request a non-canonical-loader SDK path with caller-selected FastlyGeo-CountryCode and FastlyGeo-Region headers.
3. Observe that the Didomi upstream request receives those values as Didomi geo headers.

Expected behavior

Didomi geo headers should come from trusted platform geo or be omitted. Caller-provided headers must not become authoritative geo.

Done when

• No Didomi SDK request derives geo headers from untrusted inbound request headers.
• The compatibility impact for deployments that rely on the existing headers is documented and covered by rollout guidance.
• Tests cover enabled and disabled geo_query_parameters, notice loaders, and other SDK assets.
• Cache behavior remains safe for every geo-dependent SDK response.

Affected area

Integrations (Didomi), Fastly runtime

Version

Current main; behavior predates PR #1127.