A forwarding header shorter than the hop count is read from its leftmost entry

At Trusted proxy hops 2 (Cloudflare → Traefik → app), a LAN request reaching
Traefik directly carries one X-Forwarded-For entry. trusted_entry returned None
for it, so every LAN visitor was filed under Traefik's overlay address in the
throttles and the audit log. Cloudflare's single X-Forwarded-Proto: https read
as plain HTTP, so the public road lost the Secure cookie and HSTS.

A short header now clamps to its leftmost entry, the one the first proxy wrote,
as family canon #5004 does in Minstrel, Librarian and Forge. A caller's own
entries can only make the header longer, so this trusts nothing more than before.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/public-hosting.md

@@ -60,7 +60,10 @@ traverses, so the rightmost entries are the ones your own infrastructure wrote a
 anything a caller forged sits to the left of them. Counting in from the right by the
 number of proxies you actually run means a forged prefix can never be selected. Set it
 too HIGH and it starts trusting entries no proxy of yours wrote; too low and several
-callers share one rate-limit bucket, which is merely inconvenient.
+callers share one rate-limit bucket, which is merely inconvenient. A request that
+passed fewer proxies than the count — a LAN visitor reaching your proxy directly while
+it is set to `2` for the CDN — is read from the header's leftmost entry, which your
+first proxy wrote.
 
 **4. Stop reaching the app except through the proxy.** The default compose binds
 `0.0.0.0:5000` so LAN clients can reach it directly — which is right for a LAN install