Reject malformed transcription temperature instead of reinterpreting it

[Daksha1611]

🛠 Summary

Fixes #4552.

parseTemperature() parsed the multipart temperature field with ovms::stof and, on failure, retried with ovms::stou32. ovms::stof requires the whole field to be consumed; ovms::stou32 does not, and it erases spaces first. The fallback therefore rescued exactly the values stof had just rejected, turning malformed input into a plausible temperature instead of the intended Invalid temperature type. error:

temperature=0.5x   -> accepted as 0.0, not 0.5, so sampling is silently off
temperature=0abc   -> accepted as 0.0
temperature=1e400  -> accepted as 1.0
temperature=5 5    -> accepted as 55.0

The fallback had no purpose — ovms::stof already parses integer spellings, so "1" never reached it. Every input it could rescue is malformed by definition. Removing it lets the existing error path fire.

This deliberately adds no range check. Passing a negative temperature through for GenAI to reject is the behaviour established by #4201 and pinned by negativeTemperatureEnableSampling, so I left it alone rather than quietly reverse it. Happy to revisit separately if the endpoint should enforce the OpenAI audio range at the parse layer.

Adds four cases for the spellings above. The three existing SttServableParseTemperatureTest cases are unaffected — -1.0, 0 and 1.0 all parse cleanly through ovms::stof and never reached the fallback.

The root cause is that ovms::stou32 alone among the stringutils converters does not check for a partial parse; that is #4554, and the two fixes are independent.

I have no OVMS build container available, so this is not compiled against the full tree and CI will need to confirm the build. I did check the change in isolation and verified the three existing test inputs behave identically. Draft for that reason.

🧪 Checklist

• Unit tests added.
• The documentation updated.
• Change follows security best practices.