fix(config_flow): reload entry after reauth/reconfigure when initial setup failed

[sslivins]

Problem

Fixes #283 (and matches the reports in that thread from @ASwingler, @plynkus, @cheesedogf150, @mattmeiser).

After the v1→v2 (0.5.2) upgrade, an existing entry's data has no refresh_token / dpop_pem, so async_setup_entry raises ConfigEntryAuthFailed("Missing refresh token or DPoP key"). That raise happens before entry.add_update_listener(async_reload_entry) is registered, so no update listener exists.

The user then recovers via reauth/reconfigure, which persists valid credentials with async_update_entry and relies on that (now-missing) listener to reload. With no listener, nothing reloads the entry — so it stays stuck showing "Missing refresh token or DPoP key" and the sensors never come up until a full HA restart or remove + re-add. That exactly matches every report in the issue (a restart or re-add fixes it; the update's own auto-restart does not, because the data was still the old v1 data at that point).

Fix

In _finish_reauth / _finish_reconfigure, explicitly async_schedule_reload when the entry is not LOADED (i.e. setup failed, so no listener is registered). When the entry is loaded, the reload is left to the update listener — scheduling a second reload there would race the listener-driven one and surface as "failed to unload".

Tests

• test_reconfigure_reloads_when_setup_failed — failed setup → reconfigure schedules a reload
• test_reauth_reloads_when_setup_failed — failed setup → reauth schedules a reload
• test_reconfigure_does_not_double_reload_when_loaded — a loaded entry does not double-schedule a reload

[binarydev]

LGTM thanks so much for the fix!