So, I tested the steamer functionality and it works fine.
I did notice that apparently only the MyHarvia App enforces the 140 total limit and not the API. With your HA integration it is possible to set target temperature and humidity to a total that exceeds 140 and when the sauna is turned on the Xenio doesn‘t complain and will operate at those set values. When when the MyHarvia app is started after setting those values from the HA integration the app still keeps the settings that exceed 140 and the heater can also be turned on with these values. Only when you change a value in the App it will modify the other value to not exceed 140. Maybe it is also nice to know that the app only modifies the other value when you exceed 140 total. If you set the value back then the modified other value remains. So, the app doesn‘t maintain the 140 total, it only prevents you from setting values that exceed 140.
For example: if the target temp is currently set to 90°C then the steamer humidity can be set up to 50% without any modifications to the target temp. As soon as you move the humidity to 51%, the target temp is changed to 89°C and so forth. Let‘s say you move the humidity to 60°, the target temp would be moved back to 80°C. If you then move the humidity back to 50%, the target temp remains at 80°C. But you can move the target temp back up to 90° before the humidity level is modified by the app. If you continue to move the target temp to 100°C, the app will automatically move the humidity back to 40°C.
I don‘t think anything will happen to the sauna heater when these values exceed 140. My understanding is that this is a health recomendation where they say it is not healthy when target temp and humidity together exceed 140. But, if you don‘t implement something in the integration I could imagine that Harvia at some point may try to make your integration inoperable if they find out that you allow setting the heater in this way and not honoring this behavior like the app does.
BTW: I noticed at some point the integration still stops updating states. Only after reloading the integration it pulls the current values again. The API apparently has some authentication timeout that prevents you from just polling the API to continue fetching states. Changing values still functions without reloading. So, I suppose it is an authentication issue as you probably re-authenticate when values are set and the original session has time out.