The thing to remember about Euler angles is that they're a fiction the engine generates on demand for our sake. They're not the ground truth of how rotation is stored inside the engine (that uses quaternions), and they're arguably not a natural description of the reality of 3D rotation itself.
Every 3D orientation can be represented by an infinite number of different Euler angle triples - just add or subtract a multiple of 360 on any axis for instance. Or combine rotations on different axes: {x: 180, y: 180, z: 0} is equivalent to {x: 0, y: 0, z: 180}
So when you ask Unity to translate the current orientation into Euler angles, it has to pick one standard version of those infinite possibilities to return, and that means there will be discontinuities somewhere - eg. wrapping from {89.5, 0, 0} to {89.5, 180, 180} instead of {90.5, 0, 0}. There's simply no way to write a function mapping orientations to angles that doesn't have a wrap-around anywhere.
The good news is that these still represent the orientation you expected to have, just written in a different way - like when a friend gives someone directions to a place that's different than the route you'd have chosen, but still gets them where they intended to go. ;)
This can cause trouble when we have code that's looking for specific Euler angle values, but the more robust solution there is to not write code that looks for specific Euler angle values. (Sorry, I know that sounds glib, but after answering gamedev questions here for a few years, I've found that code that does checks or math on Euler angles almost never does what its author intended for all cases that can arise in gameplay - Euler angles are very good at misleading gamedev intuition)
If you're experiencing a specific bug due to this wrapping behaviour, try asking how to solve the gameplay consequences of that bug - including the relevant code that's reading these Euler angle values - and we may be able to recommend a more robust way to phrase that code.