Reject ineffective fingerprint-forwarding carrier configurations

[hdbjeff]

Follow-up from the review of #23.

Problem

A route can request forwardFingerprint: ja3 or ja4 without selecting a carrier that can actually deliver it.

The HTTP-header carrier requires terminated plaintext HTTP/1. Passthrough and HTTP/2 require sourceAddressHeader: proxyProtocolV2. Static routes currently emit only an stderr warning for ineffective combinations, allowing an apparently healthy deployment that silently drops the requested fingerprint. Routes supplied through resolveConnection do not receive equivalent warning or validation.

This leaves downstream controls believing they receive an authoritative fingerprint when no signal is delivered.

Acceptance criteria

• Reject configurations where fingerprint forwarding has no viable carrier, rather than relying on stderr.
• Apply identical validation to static routes and routes supplied through resolveConnection.
• HTTP-header forwarding must require TLS termination and an HTTP/1 upstream path.
• Passthrough and HTTP/2 forwarding must require PROXY protocol v2.
• Validate incompatible UDS/Harper combinations where the immediate consumer does not support the selected PROXY protocol version.
• Return a construction/resolution error that identifies the route and recommends the compatible carrier.
• Add tests for valid and invalid static and resolved-route combinations.