### Note on root cause

Verified by reading the code and reproducing against a v1.92.0-line build: `/key/update` rejects any request from a non-proxy-admin whose body contains `allowed_routes` or `permissions`, based on field presence (`"<field>" in data.model_fields_set`) rather than on whether the value actually changed. An unchanged value, or an empty `[]`/`{}`, is enough to trigger the 403. Inferred (not verified in this issue): the affected clients reach `/key/update` by round-tripping the key's existing config with a changed `team_id`/budget, so the presence check fires on fields they never intended to modify.

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

Close but distinct: - #31810 and #31987 are the PRs that introduced this gate (cause, not a duplicate report). - #31958 (open) is a UI-side change that strips org/team assignment from the non-privileged edit payload; related scope, but it does not address the server rejecting an unchanged `allowed_routes`/`permissions` on `/key/update`. - #27553 already added a client-side strip of unchanged `allowed_routes` in the key-edit modal; its code comment doc…