Fix VacationHold.enabled reading the wrong JSON key

[clutch2sft]

Because the property silently defaulted to False on the missing key, an active
vacation hold would always report as off — no error, no exception, just wrong data.
Same failure mode as the other field-name mismatches already fixed in this library
(#165).

Changes

• aiolyric/objects/device.py: VacationHold.enabled now reads Enabled.
• tests/__init__.py, tests/objects/test_device.py, tests/objects/test_location.py:
  fixtures and assertions updated to match.

pytest tests/objects/ passes (3/3).

Context

Found via a Copilot review comment on a companion home-assistant/core PR
(Ocala Thermostat room-sensor work), then confirmed against a debug log already
captured from a live account rather than guessed.

[timmo001]

The API docs use lowercase vacationHold.enabled here: https://developer.honeywellhome.com/lyric/apis/get/devices/thermostats/%7BdeviceId%7D-0. Can we support both keys? Replacing it outright means responses matching the documented schema will silently return False.

[clutch2sft]

Good catch — updated to support both keys, same approach as the fix on #166:

@Property
def enabled(self):
"""Return if enabled."""
return self.attributes.get("enabled", self.attributes.get("Enabled", False))
Checks the documented enabled key first, falls back to Enabled (the casing confirmed via the live capture used to write this fix originally). Neither a docs-compliant response nor the live one should read back False now.

Also added test_vacation_hold_enabled_key_variants covering both casings plus the missing-key default, and updated the existing assertions accordingly — all green.