As a developer I want to access client metadata in handlers #89

Description

Provide a shared handler API for client IP, geolocation and TLS metadata. Main has Fastly request context and Axum request context, but no neutral ClientInfo type or extractor. Cloudflare request context retains Worker runtime handles without capturing the requested metadata. Existing ingress fidelity metadata describes request representation, not client identity/geography/TLS facts.

Steps to reproduce

1. Inspect core public modules and handler extractors.
2. Compare Fastly, Cloudflare and Axum request contexts.
3. Identify the portable handler API returning client IP, geography and TLS metadata with availability/provenance.

Expected behavior

The same handler reads supported client facts without adapter imports, and unavailable facts stay explicit.

Impact

Applications must write platform-specific code or omit client-dependent functionality.

Proposed fix

Define a small portable metadata contract and extractor/context access. Populate it during adapter conversion, distinguishing direct peers from checked effective readers and preserving absent/unsupported values. Reuse native checked ingress and Geo contracts where applicable.

Done when

• Portable IP, geographic and TLS metadata access is documented with optional/unavailable behavior.
• Fastly, Cloudflare and Axum mappings cover available facts without inventing unavailable values.
• Tests cover presence, absence, provider provenance and untrusted forwarding inputs.

Related

Parent #88; mappings #90–#92; JA4 #283; native facts #397, #432, #438. PR #409, PR #439 and PR #453 are related open implementations, not full delivery of this story.