Make first-party integration URLs root-relative

[aram356]

Closes #820

Problem

The GPT, DataDome, Permutive, Lockr, and Sourcepoint attribute rewriters rewrite a publisher's <script src> / <link href> to an absolute first-party URL built from request_host:

format!("{}://{}/integrations/gpt/script", ctx.request_scheme, ctx.request_host)

ctx.request_host is the host TS derived for the request (extract_request_host → Host/X-Forwarded-Host). When that isn't the page's own host, these URLs leak the wrong host into the HTML — e.g. the page renders https://ts.example.com/integrations/gpt/script while the address bar shows www.example.com. This shows up behind a host-rewriting dev proxy, and anywhere request_host resolves to the routing host rather than the production domain.

Fix

Emit these URLs root-relative (/integrations/...) so the browser resolves them against the page's own host:

"/integrations/gpt/script".to_string()

Correct both in production and behind a proxy, and it removes the dependency on request_host / X-Forwarded-Host derivation entirely. This matches what GTM, Didomi, Testlight, and these integrations' own inline-script rewriters already do.

Scope — full integration audit

Audited every integration's page-facing URL emission (attribute rewriters, head injectors, inline-script rewriters, config-rendered URLs):

Verdict	Integrations
Fixed (were absolute from request_host)	gpt, datadome, permutive, lockr, sourcepoint
Already root-relative	google_tag_manager, didomi, testlight, datadome client_side_tag_url (default), sourcepoint trap prefix
Correctly absolute (real external/upstream origin)	GPT/GTM/Permutive/Sourcepoint upstream fetch targets
Intentionally absolute — left unchanged	NextJS RSC/flight payload host rewriting
Server-side only — not page-facing	DataDome protection module's raw-Host read (validation API body)

These five were the only page-facing first-party URLs built from a host.

Tests

Unit tests asserting the old absolute form updated to the root-relative form (no weakening). cargo fmt, cargo clippy --workspace --all-targets --all-features -D warnings, and cargo test --workspace all pass.

[ChristianPavilonis]

Automated review: I reviewed the root-relative integration URL changes for GPT, DataDome, Lockr, Permutive, and Sourcepoint. I did not find any blocking correctness, security, data-loss, authorization, or severe compatibility issues. CI is passing. I left one non-blocking compatibility comment about <base href> semantics because root-relative attribute URLs are still resolved against the document base URL, not always the address-bar origin.

[ChristianPavilonis]

Review Summary

Approved. I reviewed the root-relative first-party integration URL change and did not find any blocker/high/medium correctness, security, or compatibility issues beyond the already-noted <base href> edge case.

Findings

P3 / Low

• crates/trusted-server-core/src/integrations/datadome.rs:55 — DataDome module docs still show the old absolute rewrite output (https://publisher.com/integrations/datadome/tags.js). Please update the example to the new root-relative form (/integrations/datadome/tags.js) when convenient.

[aram356]

Addressed review feedback in 38aee53:

• P3 (datadome.rs:55) — updated the module doc example from the old absolute https://publisher.com/integrations/datadome/tags.js to the root-relative /integrations/datadome/tags.js.
• <base href> compatibility note — documented the tradeoff at all five rewrite sites (gpt, datadome, lockr, permutive, sourcepoint), noting that a page-level <base href> participates in URL resolution. This is the intended, lighter option from the review and is consistent with GTM/Didomi/Testlight, which are already root-relative.

Comment/doc-only change; cargo fmt and cargo clippy pass.