feat: per-shade home key + improved config flow

[safepay]

Previously the home key was hardcoded in const.py and shared across all shades at the module level. This meant you had to edit source code to set it, and every shade used the same constant. This PR moves the key into each shade's config entry data and adds a proper config flow to collect it.

Home key handling

• Removed the hardcoded HOME_KEY bytes constant from const.py, replaced with a CONF_HOME_KEY config entry data field
• Coordinator now reads the key from the entry's data dict and passes it per-shade to PowerViewBLE
• Added has_key property on PowerViewBLE so cover.py can check whether encryption is available without referencing a global constant
• Cover feature flags now check api.has_key instead of comparing against the old global

Config flow

• Full config flow for collecting the home key — fetch it from a G3 hub, paste it manually, or skip for unencrypted shades
• When fetching from the hub, shade names are decoded from the API and shown in the device picker (e.g. "Master Bedroom (DUE:94ED)" instead of just the BLE name)
• Multi-select device picker so you can add all your shades in one go
• If a shade is already configured with a key, subsequent flows reuse it automatically and skip the key step
• BLE auto-discovery flow also inherits the key from existing entries
• Defaults to "fetch from hub" as the key method since that's the common path

extract_gateway3_homekey.py

• Better error handling — unreachable shades no longer abort the whole script, and the network key from a reachable shade is used as a fallback
• Improved error messages with actual error codes and data

Housekeeping

• Version bump to 0.24
• Closes [FR] Store the HOMEKEY in the component configuration #8

[patman15]

Great, thanks for that input! I'll have a look and come back with potential issues or do you want me to change/fix them directly?
Is there a reason you made the key per shade? Usually, a full home has only one key.

[safepay]

No worries!

The key is home-wide — it's the same for all shades on a home. It's stored per-entry because each HA config entry needs to be self-contained (entries can be removed independently). The user is only prompted once; subsequent shades auto-inherit it via _existing_home_key(). Happy to refactor to a hub-based parent entry if you'd prefer that pattern.

Just provide feedback and I can fix. Sorry about the double/huge PR's, but in my local testing everything is looking good and very up-to-date.

I'll look at those linting and hass failures.

[safepay]

PR #29 is a better architecture.