A clamped shed rate is not a change

[bjmeetsfo]

put_proxy_group stores drop_percent clamped to 100, and decided whether
anything changed by comparing the raw request against the stored value.
So a group asking for more than 100 never matched itself:

put(drop_percent: 250)  -> stored 100, config_version 1
put(drop_percent: 250)  -> stored 100, config_version 2
put(drop_percent: 250)  -> stored 100, config_version 3

The comment on that comparison says what it is for: "Only a change proxies
must act on bumps the version; re-putting an identical group leaves
attached proxies undisturbed." A re-put is how a control loop keeps a
group declared, so every round told every attached proxy its config had
changed, forever, over a value that never moved.

The change history had the same split. It recorded the requested number,
so it read drop_percent=250 for a group shedding 100 -- the one place an
operator would look to find out what the group is actually doing.

Clamp once, before anything compares or records it, so the comparison, the
stored value and the history all mean the same number.

Tests: re-putting an out-of-range group leaves config_version alone while a
genuine change still moves it, and the history reports the rate that took
effect. Both fail beforehand -- the first with "re-putting the same group
moved config_version", the second with drop_percent=250 recorded for a
group shedding 100.