Cloudflare ClientInfo #91

Description

Capture Cloudflare client metadata through the portable ClientInfo contract. Cloudflare request conversion copies request headers and constructs the neutral request, while Cloudflare request context preserves Env/Context only. It does not retain the request cf metadata or parse CF-Connecting-IP into a shared typed fact.

Steps to reproduce

1. Inspect Cloudflare into_core_request and CloudflareRequestContext.
2. Trace whether request cf geography/TLS metadata survives conversion.
3. Look for a typed CF-Connecting-IP mapping and portable handler access.

Expected behavior

Cloudflare handlers can read available IP/geographic/TLS facts through the shared API, with unavailable or malformed values explicit.

Impact

Copying raw headers alone leaves handlers to reimplement Cloudflare metadata parsing and source assumptions.

Proposed fix

Populate #89 from runtime cf facts and platform-provided client-IP metadata before the native request is consumed. Document trusted runtime boundaries and absence in local environments; validate values without treating arbitrary client assertions as provider facts.

Done when

• Available cf and client-IP fields populate the portable metadata contract.
• Missing/malformed metadata has deterministic absent/error behavior.
• Worker runtime contracts cover populated metadata and local/runtime absence.

Related

Parent #88; story #89; sibling mappings #90, #92.