I have discovered the reason this happens, and as is often the case, the answer is that it's insufficient documentation and poor error handling by Google.

The root cause is someone making an edit to the series at any point and choosing "this and future events" for which events they'd like the change to apply. When this happens, Google creates a new series event with an ID like that of the original recurring event, followed by "_R" followed by the timestamp at which the series was split. So for example, 0mku05shes4kef7fg5gvh2me57 is followed by a new recurring event, 0mku05shes4kef7fg5gvh2me57_R20251015T021500.

Once this happens, the original event will refuse any further attempts at extending the UNTIL value in the RRULE, and unfortunately as outlined in the question, it does so silently: the request gets a 200 response and a valid response, but simply discards the change. It's somewhat sensible not to change this value, because then events from the original series would begin to encroach upon events from the new series. (What's not sensible is silent failure: this really should result in a 400 response with a useful error message from the API.)

There is unfortunately no linkage visible via the API between the original recurring event and the replacement recurring event, though at least as long as Google doesn't change their ID scheme, it's possible to figure out the original recurring event ID from the new recurring event ID and to work backwards. This linkage must exist on Google's side, however, because they know to reject the update to UNTIL, and if you cancel the replacement recurring event, it again becomes possible to extend the original recurring event. Also if you cancel the original recurring event, it will cancel both the original and the replacement recurring event (as one would probably expect).

Hopefully this post will be sufficiently searchable that the next time someone runs into this problem, it will save them some time figuring it out.