Reject ineffective fingerprint-forwarding carrier configurations

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.

Trace static route construction and routes supplied through resolveConnection, starting from the existing stderr warning for ineffective fingerprint forwarding. Review the route-related tests and add coverage for valid and invalid static and resolved-route combinations; done means construction or resolution rejects incompatible carriers with a route-specific recommendation.

Written by the indexing model from the issue text.