fix(config): clean up orphaned battery-schedule entities and stale docs left by #873's removal

[woopstar]

Description

#873 (refactor/860-remove-battery-schedules, merged into main as 1e721081)
removed the fixed battery discharge/charge-schedule feature
(batteries_schedule_1/2/3) — the config-flow step, the six
hsem_batteries_enable_batteries_schedule_* config keys, the 3 switch
entities, and the 6 start/end time entities. The removal was correct (the
feature was confirmed inert whenever MILP is active — see #860), but two
things were left behind:

1. Orphaned entity-registry rows (no cleanup migration).

custom_components/hsem/switch.py and time.py no longer create these 9
entities, but nothing ever removes their registry rows for existing
installs:

• Switches (custom_components/hsem/utils/sensornames/controls.py, deleted
  by refactor(planner): remove the inert battery-schedule feature #873): hsem_{entry_id}_hsem_batteries_enable_batteries_schedule_{1,2,3}_switch
• Times: hsem_{entry_id}_hsem_batteries_enable_batteries_schedule_{1,2,3}_start_time
  and ..._end_time

This repo has an established pattern for exactly this situation —
custom_components/hsem/flows/migrations.py:153-165
(_remove_v3_charge_rate_registry_entries), called from
config_flow.py's async_migrate_entry when the retired charge-rate
learner's 7 number entities were removed in the v2→v3 config migration.
#873 didn't add an equivalent step, and config_flow.py:101's VERSION
is still 3 — no version bump, no migration hook fired. Existing installs
that upgrade to a build containing #873 will see all 9 entities linger in
the registry as "unavailable" under the Battery & Energy device until a
user manually deletes them.

The orphaned config keys (hsem_batteries_enable_batteries_schedule_* and
the six start/end time keys) are harmless — nothing reads them anymore —
so no data migration is needed for those, only the registry cleanup.

2. Stale documentation describing battery scheduling as a live feature.

• README.md:80 — Quick Start step 4: "Set up battery schedules in
  HSEM (do not use Fusion Solar app for scheduling)." — tells brand-new
  users to configure a feature that no longer exists.
• README.md:157 — wiki-link description still lists "battery schedules"
  as a covered topic.
• docs/index.md:11-12 — same, in the docs table of contents.
• docs/sensors-reference.md:31 — the "Battery & Energy" row of feat(home-assistant): split HSEM into 7 per-subsystem devices #910's
  device-mapping table still lists "battery schedule 1/2/3 switches and
  start/end times" as entities on that device. This table was written
  by feat(home-assistant): split HSEM into 7 per-subsystem devices #910 before refactor(planner): remove the inert battery-schedule feature #873 merged, so refactor(planner): remove the inert battery-schedule feature #873's own doc-update pass never saw it.
• docs/troubleshooting-guide.md:334,386,437,512,517 — five separate
  troubleshooting entries instruct users to "check your battery schedule"
  or "enable a battery schedule in the config flow" as the fix.
• docs/safety-modes.md:117 — describes set_tou_periods as being
  "applied according to the current battery schedule"; TOU periods are now
  driven directly by the planner's current recommendation, not a schedule.
• docs/battery-charging-economics.md — titled "How to Calculate the
  Minimum Charging Price for a Battery Schedule". The underlying
  depreciation/cycle-cost math is still valid and still used (Excess
  Battery Export, MILP cost function) — only the "for a Battery Schedule"
  framing in the title and intro is stale; the doc's content doesn't need
  a rewrite, just a retitle/reframe.

Possible Solution

Registry cleanup — add a v3→v4-style step following the exact
_remove_v3_charge_rate_registry_entries pattern:

1. Bump HSEMConfigFlow.VERSION to 4 in config_flow.py.
2. Add _remove_battery_schedule_registry_entries(hass, entry_id) to
   flows/migrations.py, removing entity-registry rows for the 9
   unique_ids listed above (switch + time domains), and call it from
   async_migrate_entry for entries below version 4.
3. No data/options key migration is needed (_migrate_v3_to_v4 can be
   a no-op passthrough, or skipped if the existing migration dispatch
   doesn't require one) — only the registry-removal side effect.
4. Add a test in tests/test_config_flow_migrate_unique_ids.py (or
   wherever the v2→v3 registry-removal test lives) asserting the 9
   entities are gone after migration and that a second run is a no-op.

Docs cleanup — for each file above, remove or reframe the
battery-schedule references so they reflect the current (MILP-only,
no fixed schedules) behaviour:

• README.md — drop or replace Quick Start step 4 with something
  accurate (e.g. pointing at EV charging / excess export setup instead).
• docs/index.md, README.md:157 — drop "battery schedules" from the
  topic lists.
• docs/sensors-reference.md:31 — remove the battery-schedule mention
  from the Battery & Energy row (it should just list battery SoC,
  effective discharge floor, net consumption, PV curtailment,
  charge/discharge efficiency numbers, dynamic discharge floor switch —
  matching what's actually still in switch.py/custom_sensors/).
• docs/troubleshooting-guide.md — rewrite the 5 affected entries to
  describe the current MILP-driven TOU/discharge behaviour instead of a
  battery schedule the user can no longer configure.
• docs/safety-modes.md:117 — reword to "applied according to the
  current planner recommendation".
• docs/battery-charging-economics.md — retitle (e.g. "How to Calculate
  Battery Depreciation Cost per kWh") and adjust the intro paragraph;
  leave the cycle-cost math itself untouched.

Run ./scripts/quality.sh translations if any user-facing string
(not just docs) changes as part of this — unlikely here since this is
docs + a registry migration, not new config-flow strings, but verify.

Acceptance Criteria

• HSEMConfigFlow.VERSION bumped; existing v3 entries migrate cleanly
  to v4 on next HA restart/reload.
• The 9 battery-schedule switch/time entity-registry rows are removed
  for any entry that still has them; migration is idempotent (a second
  run is a no-op, matching the existing v3 migration's guard pattern).
• No stale reference to "battery schedule[s]" as a currently
  configurable feature remains in README.md, docs/index.md,
  docs/sensors-reference.md, docs/troubleshooting-guide.md,
  docs/safety-modes.md, or docs/battery-charging-economics.md
  (historical/removal notes in docs/planner-spec.md and
  docs/candidate-generation.md are correct as-is and out of scope).
• Tests added covering the new registry-cleanup migration step,
  mirroring the existing _remove_v3_charge_rate_registry_entries
  coverage.
• ./scripts/quality.sh all passes.

Suggested Prompt

Run the hsem-pre-flight skill first (checkout main, pull latest, create a
feature branch). Then fix two related gaps left behind by #873's removal
of the battery-schedule feature (already merged to main as 1e721081):

1. Registry cleanup: config_flow.py's VERSION is still 3 with no migration
   step that removes the 9 now-dead entity-registry rows for the batteries
   schedule switches/times (3 switches: hsem_{entry_id}_hsem_batteries_enable_batteries_schedule_{1,2,3}_switch;
   6 times: hsem_{entry_id}_hsem_batteries_enable_batteries_schedule_{1,2,3}_start_time
   and ..._end_time). Follow the exact existing pattern in
   flows/migrations.py's _remove_v3_charge_rate_registry_entries()
   (lines ~153-165) and its call site in config_flow.py's
   async_migrate_entry — bump VERSION to 4, add an equivalent
   _remove_battery_schedule_registry_entries() function, wire it in, and
   add a test mirroring whatever test covers the v3 charge-rate cleanup.

2. Docs cleanup: remove/reframe every reference to battery scheduling as a
   currently-configurable feature in README.md (line ~80 Quick Start step
   4, and line ~157), docs/index.md (lines ~11-12), docs/sensors-reference.md
   (line ~31, the Battery & Energy device-table row), docs/troubleshooting-guide.md
   (5 entries around lines 334/386/437/512/517), docs/safety-modes.md
   (line ~117, TOU periods description), and docs/battery-charging-economics.md
   (retitle away from "for a Battery Schedule" — the depreciation/cycle-cost
   math itself is still valid and used elsewhere, don't touch that content).
   Do NOT touch docs/planner-spec.md or docs/candidate-generation.md — those
   already correctly document the removal as history.

Run ./scripts/quality.sh all before opening the PR. Activate hsem-doc-sync
to double check no other doc references were missed, and hsem-pr-workflow
before opening the PR.