Harden thermostat validation and improve Italian responses

[f3rs3n]

Summary

This updates Thermostat Control to normalize numeric input before arithmetic and reject invalid requests before reporting success.

• normalize numeric input, including Italian un/uno/una, due through dieci, and decimal commas;
• improve Italian responses with grado/gradi agreement;
• reject missing or invalid amounts, non-positive deltas, off or unsupported modes, and out-of-range targets, including heat_cool ranges;
• call climate.set_temperature before emitting a success response;
• add localized validation errors for every advertised language;
• bump the blueprint to 1.1.7 and update the changelog.

Validation

• focused contract: RED on 1.1.6, GREEN on the candidate;
• 10 validation cases, 7 target calculations, and 40 multilingual rejection checks passed;
• YAML/Jinja validation, git diff --check, and the Docusaurus production build passed;
• CRLF blueprint formatting was preserved.

I am a native Italian speaker and personally reviewed the Italian text, complete diff, and test results. AI tools assisted with research, testing, and drafting.

[dinki]

Thank you for the work on this. Most of it looks great but I do have questions about:

  - variables:
      amount_words_it:
        un: 1
        uno: 1
        una: 1
        due: 2
        tre: 3
        quattro: 4
        cinque: 5
        sei: 6
        sette: 7
        otto: 8
        nove: 9
        dieci: 10
      amount_number: >-
        {% set raw = trigger.slots.amount | default('') | string | lower | trim -%}
        {% set normalized = amount_words_it.get(raw, raw | replace(',', '.')) if language == 'it' else raw | replace(',', '.') -%}
        {{ normalized | float(default=none) }}
      degree_word: "{{ 'grado' if amount_number == 1 else 'gradi' }}"

I have attempted to keep all of the translation related values in the translations dictionary. Do you think it would be possible to move these additional variables within the Italian definition? Some logic would need to be used for setting the values for the amount based on what language is selected of course.

[f3rs3n]

You're right — this locale-specific data should have lived under the Italian translation, and I should have caught that before submitting. Sorry about that.

I've moved the number-word map and singular/plural degree labels under translations.it; the shared normalization logic now selects optional locale data through translations[language], with numeric parsing preserved for languages without a word map. I reran the focused equivalence checks, YAML/Jinja validation, CRLF checks, and the wiki build.

[dinki]

Thanks for the quick turnaround. I hope to revisit this soon. My work and home life has been insane lately so forgive my tardiness.