fix(web): stop double-marking manually overridden plan rate cells

[chalfontchubby]

Summary

Reported as "double F on a doubly-overridden cell, can't clear either" - traced this down against a reporter-supplied debug.yaml/log.

The backend is fine: manual_select() (userinterface.py) already explicitly removes any existing override for a time slot before adding a new one - confirmed via the reporter's own log, which shows Removed existing rate override for Mon 14:30 before adding new value firing correctly, and a subsequent single Clear fully removing it. There's no "stacking" at the data level.

The bug is in the editable plan table's rendering (web_helper.py). Two independent signals both mark an overridden cell with the same turned-F glyph (ⅎ):

1. row.{import,export}_rate_adjust_type === 'manual' (server-computed) → rendered via getAdjustSymbol('manual'), baked into the cell text before it's handed to renderRateCell().
2. renderRateCell()'s own isOverride check, matched separately against the overrides.manual_{import,export}_rates array by minute.

Both fire for the same single override, stacking two identical markers on one cell. Worse: the Clear link is gated only on signal 2 (isOverride) - so if the two signals ever disagree (which the report's "can't clear it" symptom implies they can), you get a marker with no working Clear behind it, and the reporter's only path back to normal was restarting HAOS.

Fix

Skip the adjust-type marker specifically for 'manual' when the cell is editable, since renderRateCell() already fully owns the marker + Clear UI for that case - isOverride becomes the sole source of truth for both, so the two can no longer disagree. Other adjust types (offset/future/user/increment/saving) aren't part of the clickable-override mechanism and keep their existing marker.

Also hardened toggleForceDropdown() with a null guard - document.getElementById(id) returning nothing would previously throw silently, indistinguishable from a cell just not responding to clicks. This is a separate symptom also reported alongside the double marker (a cell that won't even open its dropdown) that isn't fully root-caused yet - the guard makes the failure mode loud (console.warn) instead of silent, so it's diagnosable next time rather than requiring a restart to move past.

Test plan

• New regression tests in test_plan_why_reason.py (structural JS-source assertions, following that file's existing pattern) covering both the marker de-duplication and the null guard
• ./run_all --test plan_why_reason passes
• ./run_all --quick - all tests pass
• ./run_pre_commit - clean

Fixes #4474.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes a Web UI rendering issue in Predbat’s editable Plan table where a single manual rate override could be marked twice (double turned-F glyph) and, in some cases, leave a visible override marker without a working Clear action. It also hardens dropdown toggling to avoid silent failures when a stale dropdown id is clicked.

Changes:

• Prevent duplicate manual-override markers by suppressing the adjust-type glyph for manual rates when the plan table is editable (leaving renderRateCell() as the sole source of truth for the marker + Clear UI).
• Add a null-guard in toggleForceDropdown() and emit a console.warn when the target dropdown element is missing.
• Add regression tests in test_plan_why_reason.py to assert both the marker de-duplication and the new null-guard behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
apps/predbat/web_helper.py	Avoid double-marking manual overrides in editable rate cells; add safe dropdown toggling with warning on missing element.
apps/predbat/tests/test_plan_why_reason.py	Add structural JS-source regression assertions for the manual marker de-duplication and toggleForceDropdown() null guard.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.