Derive Lockr API Origin from Referer for first-party proxy

[aram356]

Closes #832

Problem

Behind the first-party proxy, the Lockr settings call returns success-shaped HTTP 200 but a failure body:

{"success":false,"error":{"code":400,"message":"Invalid request"}}

The SDK's getAIMSettings() only proceeds when success === true && data, so the entire init chain short-circuits — no settings data, no pvStatus, no page-view, and no identity tokens.

Root cause

The Lockr identity API (identity.loc.kr) requires the publisher's Origin header. When a browser calls the API directly it is cross-origin, so the browser attaches Origin automatically. Behind the first-party proxy the browser calls /integrations/lockr/api/... on the same origin as the page, so it sends no Origin.

copy_request_headers only set Origin from a configured origin_override or a pre-existing request Origin — neither present in the first-party case — so the proxied request reached the upstream with no Origin and was rejected.

Verified by direct replay against the upstream: the same body with no Origin is rejected, while supplying the publisher Origin gets past that check.

Fix

In the Lockr API proxy's copy_request_headers:

• Synthesize the publisher Origin from the page Referer when the request has no Origin and no origin_override is configured. The same-origin call still carries a Referer (the page URL), whose origin is exactly the value a direct cross-origin call would have sent.
• Forward the Referer header upstream so the proxied request matches a direct browser call.

Precedence: origin_override → request Origin → Referer-derived origin.

Note: deriving the origin from the request Host is deliberately avoided — edge host-rewriting can make Host differ from the publisher's registered domain. Referer reflects the actual page origin.

Testing

• New unit tests: derive Origin from Referer; prefer an explicit request Origin; prefer origin_override; and origin_from_url extraction (path/query/fragment stripped, scheme-less rejected).
• cargo test -p trusted-server-core lockr — 13 passed.
• cargo fmt --all -- --check and cargo clippy -p trusted-server-core --all-features — clean.

Verification note

End-to-end browser verification requires a deployment of this change (the live first-party endpoint runs the deployed build); the fix is covered by unit tests and an upstream replay that isolates Origin as the cause.

[aram356]

Closing — the Origin theory was a misdiagnosis. Verified against the live upstream and the deployed server: the failure is the proxy not forwarding the POST body (upstream returns 400 Invalid request for an empty body; a missing Origin returns 500, which is not the observed symptom). Sending the deployed server a fully-correct request (valid Origin + content-type + body) still returns 400, so the body is being dropped. POST-body forwarding is already fixed in main (#624); the deployed build predates it. origin_override is unrelated to this failure. Tracking the real cause in #832; regression test in the new PR.