Cloudflare adapter: derive request scheme from trusted cf-visitor header, strip spoofable forwarded headers #828

Description

Follow-up from PR #643 review (inline comment).

In the Cloudflare adapter, build_runtime_services sets tls_protocol/cipher to None, and nothing strips or injects an authoritative request scheme. As a result, core detect_request_scheme falls back to the client-controllable X-Forwarded-Proto / Forwarded headers.

Impact is bounded today — EC cookies are hardcoded Secure (verified at crates/trusted-server-core/src/ec/cookies.rs:93,202,374), so this is not a blocking issue. It is tracked as hardening to match the Fastly adapter's behavior.

This relates to the earlier general fix in #409 (X-Forwarded-Host / Forwarded spoofing), applied here specifically to the Cloudflare entry point.

What to do

• Derive the request scheme from the trusted cf-visitor header (Cloudflare sets {"scheme":"https"}) in the Cloudflare adapter.
• Strip the spoofable X-Forwarded-Proto and Forwarded headers before they reach core scheme detection.
• Mirror the Fastly adapter's scheme-hardening approach so all entry points behave consistently.

Done when

• Cloudflare adapter sets an authoritative scheme from cf-visitor (not client headers).
• X-Forwarded-Proto / Forwarded cannot influence detect_request_scheme on the Cloudflare path.
• Behavior matches the Fastly adapter; covered by a test.

Affected area

Core (Edge Cookies, GDPR) / Cloudflare runtime