Relay cannot represent per-request public scheme for mixed-scheme host aliases

## Problem

The relay correctly derives the tenant authority from the inbound `Host`, but it derives the scheme for signed and advertised URLs from one deployment-wide `RELAY_URL`.

That works for an ordinary TLS-terminating proxy when `RELAY_URL` is the public `wss://` URL. It cannot represent one relay that is intentionally reachable through endpoints with different transport posture, for example:

- `ws://relay.internal:3000` from an isolated private network; and
- `wss://chat.example.com` through a TLS-terminating edge proxy.

Whichever scheme `RELAY_URL` selects, the other endpoint disagrees. The mismatch affects more than generated links:

- NIP-98 verification reconstructs the wrong `http`/`https` URL;
- NIP-42 reconstructs the wrong `ws`/`wss` relay tag;
- git smart HTTP authentication fails similarly;
- media descriptors, NIP-05 relay hints, NIP-11 push origin, push-lease validation, and invite links use the wrong public scheme.

This becomes directly relevant if one of the host-alias approaches in #4952 / #5410 / #5674 is accepted.

## Security constraint

PR #261 deliberately stopped trusting attacker-controlled `X-Forwarded-*` values during NIP-98 verification because forwarded host/proto could enable cross-relay replay. I do not think the relay should trust forwarded host again.

A narrow design could reconstruct **scheme only** when all of these hold:

1. the direct TCP peer is in an explicit operator allowlist of exact IPs/CIDRs;
2. the edge overwrites, rather than appends to, `X-Forwarded-Proto`;
3. exactly one header field with exactly `http` or `https` is present;
4. forwarded host is ignored; tenant selection and URL authority continue to use the normalized inbound `Host`; and
5. empty/unset trust config preserves current behavior.

The deployment would also need to ensure the relay is reachable only through the trusted proxy; trusting an entire container subnet that arbitrary workloads can enter would not be sufficient.

## Question

Is mixed-scheme multi-address serving a supported topology the relay should model, or should every authority for a deployment be required to use the one public scheme configured by `RELAY_URL`?

If the former, would a direct-peer allowlist plus scheme-only `X-Forwarded-Proto` be acceptable given the #261 precedent? I can send a focused implementation with end-to-end NIP-98/NIP-42 coverage and no forwarded-host handling after the direction is agreed.

Start by reviewing PR #261 and the current RELAY_URL handling, then trace how NIP-98, NIP-42, and the other listed URL consumers derive their scheme. First establish whether mixed-scheme multi-address serving is supported; if it is, completion requires agreed trust behavior plus end-to-end NIP-98/NIP-42 coverage without forwarded-host handling.

Written by the indexing model from the issue text.