Charge the rate limit to the client, and stop the map growing without bound

[Shine-neko]

The limiter keyed its buckets on the leftmost X-Forwarded-For entry, taken straight off the request:

.get("x-forwarded-for").and_then(|v| v.split(',').next())

That entry is written by the client. A fresh forged value per request bought a fresh bucket per request, so the limiter never fired on the traffic it exists to hold back — and resolve_client_ip was right there, already used by ip_allow_list, which only believes the header when the peer is a trusted proxy. The limiter now goes through it, so a header from an untrusted peer is ignored and one from a proxy we trust is still honoured.

Every forged value also left a permanent entry behind. cleanup existed to prevent exactly that, carried a comment saying so, and was marked #[allow(dead_code)] — nothing called it. check now sweeps once the map crosses 10k sources: idle buckets first, and if a flood of fresh addresses leaves nothing idle, the buckets closest to full. A source at full tokens has spent nothing, so forgetting it grants it nothing; a depleted bucket — the one that is being held back — outlives it.

The tests fail against the old behaviour, showing two forged headers resolving to two identities, and 15000 sources tracked against a 10000 cap.

Fifth of the findings from a full audit, after #140 to #143.