Make trusted client-IP handshake degradation observable

[prk-Jr]

Description

Follow-up from the review of #1048 (#1048 (review)).

When [trusted_client_ip] is configured, the Fastly adapter falls back to the immediate peer address whenever the authentication header is missing, duplicated, mismatched, or the IP value fails to parse. That fallback is logged at debug level on purpose — the inputs are client-controlled, so warn/error would let a client drive log volume.

The consequence is that a real operational failure is invisible in production: a rotated-but-unsynced shared secret, or a renamed front-door header, silently degrades geo lookup, EC derivation, and bot protection to Fastly edge-node addresses with no operator-visible signal.

Done when

• A fallback-with-config-present signal is emitted in a form operators can alert on (for example a counter or rate in telemetry), without letting client-controlled input drive unbounded log volume.
• Or: a synthetic check asserts that a forwarded client address round-trips end to end, so a broken handshake fails a monitored probe.
• The chosen mechanism is documented in docs/guide/fastly.md alongside the trusted client-IP setup steps.

Affected area

• crates/trusted-server-adapter-fastly/src/platform.rs (fallback path)
• crates/trusted-server-adapter-fastly/src/compat.rs
• docs/guide/fastly.md