Fix: avoid assigning to read-only config_entry in OptionsFlow (fixes options UI 500 error)

[jelofsson]

This fixes a 500 error when opening the Greenely integration Options (Configure) UI.

Background:
Historically integrations could set self.config_entry (though it was discouraged and logged a deprecation warning). Beginning with Home Assistant Core 2025.12 the deprecation period ends, self.config_entry becomes truly read-only and attempting to assign to it raises an AttributeError (which produces the 500 error shown in the UI).

What I changed:

• Store the passed ConfigEntry in a private attribute instead:
  • self._config_entry = config_entry
• Use self._config_entry.options.get(...) to populate option defaults in the options schema.
• Corrected the type hint in async_get_options_flow to accept a ConfigEntry.

Tested:

• Restarted Home Assistant and verified the Options (Configure) form opens without the AttributeError / 500 error.
• Verified option defaults load correctly from the stored config entry, And that changes are saved and loaded correctly.

[emanuelstrom]

Confirmed working on Home Assistant 2026.4.4. Without this fix, opening Configure on the Greenely integration returns a 500 Internal Server Error and the options form never loads — making it impossible to enable Hourly Usage / Daily Produced Electricity etc. after the initial setup.

I cherry-picked this commit on top of #68 (which fixes the related blocking-call warnings) into a fork I'm running, and verified:

• ✅ Options flow opens cleanly, no 500
• ✅ Existing values pre-populate correctly from _config_entry.options
• ✅ Saved changes are persisted and reload of the integration picks them up
• ✅ Default values for unset options (e.g. daily_produced_electricity=False) load correctly

Would be great to get this merged — the options flow is currently broken for everyone on HA Core 2025.12+ until then.

Thanks @jelofsson for the clean fix!