fix: parse comma-separated X-Forwarded-Proto in Scheme

[sonnemusk]

Summary

Context.Scheme() treated the entire X-Forwarded-Proto header as one token. Multi-proxy values like https, http failed validation and were ignored.

Change

• Introduce firstValidProto to take the left-most valid scheme token.
• Apply to X-Forwarded-Proto, X-Forwarded-Protocol, and X-Url-Scheme.
• Add unit tests for comma-separated headers.

Test plan

• go test . -run TestContext_Scheme

[aldas]

in which case that header has comma separated values? When I read https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto it only seems to refer single value

[sonnemusk]

Agreed that MDN describes a single token. Multi-value X-Forwarded-Proto is non-spec but does show up in the wild when:

1. Proxy chains append — some L7 hops (certain nginx/ingress/service-mesh configs) append instead of replace, producing values like https, http.
2. Multiple header lines — Header.Get joins with ", " for multi-value headers in Go, so two X-Forwarded-Proto lines become a comma-separated string even if each was single-valued.
3. Other frameworks already defensive-parse — e.g. similar left-most-token handling exists in common Go HTTP stacks for forwarded headers.

If you’d rather not support the multi-value case, I can close this and leave Scheme as strict single-token. The multi-value path was meant as defensive parsing, not a claim that MDN documents commas.