UX-10: the last plain-language leftovers: log lines, two table rows, 'Why: Other', red at 0 s

- test_messages.py part 6: every dynamic part of a WARNING+ line is classified
  as data or as a built text, and every built text is produced by the real
  code and checked. This is the gap the 2d scan had: it counted `%s` as one
  word, so reasons built by loop_clamp_note() and friends were never seen.
- Quoted reasons rewritten to STYLE.md (red-alarm shape, codes kept):
  OUTPUT_CLAMP, METER_FROZEN, CIRCULATING_POWER, STALE_READING, the peak
  guard (codes now PEAK_GUARD*), the migration report, price feed, price
  history and gate reasons. Plurals via messages.times()/count().
- Top table: Price history "96 prices over 24 hours for 26 Sep", Tariff
  "one every 15 minutes or every hour", "not final yet" dropped.
- Levels and noise: per-cycle shadow line DEBUG, shadow on/off INFO,
  aiohttp access log only at log level debug, settings warnings once per
  start, one plain line per Home Assistant outage (hass.Outage).
- INFO jargon and error texts: no "§8.3", ISO times, "banked", "keys ARE",
  "NOT_OBSERVED", "did NOT land", "AND".
- Display bugs: WHY_WINNER covers every winner and safety reason
  (main.why_key(), part 7 finds them in the code); the meter row is amber
  "waiting for the first reading" inside its limit after a start; the
  missing-reading age is counted when the page asks.
- STYLE.md and DECISIONS/UX-08-short-notifications.md (UX-10 section).

No change to safety behaviour, alarm levels, notification ids, triggers,
cadence or the banner cascade. One row colour changes (meter at start),
justified in DECISIONS.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

goodwe_controller/DOCS.md

@@ -1639,7 +1639,7 @@ is the design rather than an accident: it is 1.0 at the top of the quarter and
 grows, so the guard is gentlest when its projection rests on the least evidence
 and becomes aggressive only once the quarter is nearly measured.
 
-**The ceiling** is `peak_cap_w`, raised to the month's banked peak when that
+**The ceiling** is `peak_cap_w`, raised to this month's recorded peak when that
 already stands higher — once a month's bill is set at 5013 W, holding later
 quarters to 3500 W buys nothing and costs real charging. **That relaxation is
 granted only by an OBSERVED reading:** a peak store that cannot be read leaves the
@@ -1716,7 +1716,7 @@ exactly like the SoC drift the monthly maintenance cycle exists to correct.
   **nothing more**. See below for what that costs on a real evening.
 - **When it binds you are told**, once per episode, with notification
   `goodwe_peak_soc_floor` and a red status-page row reading *Battery at its
-  peak reserve* (`PEAK GUARD FLOOR-LIMITED` in the log): the quarter **will**
+  peak reserve* (`PEAK_GUARD_FLOOR_LIMITED` in the log): the quarter **will**
   go over the ceiling, so shedding load is
   the only thing left that changes the bill. Failing to shave is never silent —
   the euro figure is the whole point of the guard.
@@ -1758,7 +1758,7 @@ because the guard it bounds is not the thing doing the discharging.
 
 **And the two can happen in the same cycle.** On the high-load block of the same
 day (15:00–17:00 UTC) with the pack below the floor, the guard reports
-`PEAK GUARD FLOOR-LIMITED` — *"commanding no forced discharge"* — on 49 cycles,
+`PEAK_GUARD_FLOOR_LIMITED` — *"there is no forced discharge"* — on 49 cycles,
 and on **all 49 of them** the loop is simultaneously being granted a discharge of
 up to 2000 W by the arbiter. The status page is telling you the truth about the
 guard while the battery empties.
@@ -1848,14 +1848,14 @@ Both are watched. A guard that watched only the emitted value would be silent on
 every standard configuration.
 
 **The integrator bound is not a bug, and it is reported as what it is.** It
-reads *"the loop's integrator reached its +5000 W anti-windup bound; the loop's
-command this cycle was +2000 W"*, titled *"the control loop is at its integrator
-bound"*, logged as a `WARNING`, with an amber (not red) status row and its own
-notification (`goodwe_integrator_bound`), so it never replaces a BUG SIGNAL
-notice still on screen. Brief
-engagements after a large load or solar step are normal. If it stays engaged,
-check that the battery is following its commands. Only a command over the rating
-carries the BUG SIGNAL text, and it has its own notification budget.
+reads *"the correction the add-on builds up reached its +5000 W limit. The
+command this cycle was +2000 W"*, titled *"Battery is not keeping up"*, logged
+as a `WARNING`, with an amber (not red) status row and its own notification
+(`goodwe_integrator_bound`), so it never replaces a software-fault notice still
+on screen. Brief engagements after a large load or solar step are normal. If it
+stays engaged, check that the battery is following its commands. Only a command
+over the rating is logged as a software fault, at `ERROR`, and it has its own
+notification budget.
 Why: [`DECISIONS/SAFETY-40-the-integrator-bound-is-not-a-bug.md`](DECISIONS/SAFETY-40-the-integrator-bound-is-not-a-bug.md).
 
 ### The frozen-meter alarm
@@ -2444,7 +2444,7 @@ since TARIFF-11 that row carries the provider plan itself:
 ```
 Tariff: No fixed tariff set. Price plan from 412 s ago, for 48 hours ahead:
         day-ahead prices from the price feed, 60 prices over 33 hours,
-        36 published and 24 estimated, 900+3600 s apart, not final yet
+        36 published and 24 estimated, one every 15 minutes or every hour
 ```
 
 ⚠️ **The two halves of that row are not computed at the same moment, and the
@@ -2461,9 +2461,10 @@ Read the plan half as five separate facts: which *product* the feed publishes
 and whether it came from the feed or from your fixed tariff, how many
 **prices** it carries and how many **whole hours** they cover, how many are
 **published** (firm, for their own interval) against **estimated** (carried
-from yesterday under §8.3), how far **apart** they are in seconds — `900+3600`
-is the normal mixed steady state, quarter-hourly firm points beside hourly
-carried ones — and `not final yet` (provisional) whenever any is estimated.
+from yesterday under §8.3), and how far **apart** they are — "one every 15
+minutes or every hour" is the normal mixed steady state, quarter-hourly firm
+points beside hourly carried ones. The plan is provisional exactly when some
+prices are estimated, so the estimated count says it.
 
 ⚠️ **Points and hours are two different numbers and this row used to print one
 of them under the other's name.** `words` was `f"… {len(points)} h"`, so a
@@ -3204,7 +3205,7 @@ ends. That row says how to clear it.
 | Row starts with | What it tells you |
 |---|---|
 | Control | When control last ran. Red when it has stopped running: the control board then sets the inverter to 0 W. |
-| Meter | The grid reading, its age, how many readings were refused, and how long its value has not changed. |
+| Meter | The grid reading, its age, how many readings were refused, and how long its value has not changed. Just after a start it is amber and *waiting for the first reading*. Red means no reading for longer than the limit. |
 | Stuck-meter check | Whether the add-on can warn you about a stuck meter. |
 | Meter reading may be stuck | See *Meter reading may be stuck* under Notifications. |
 | Month peak | This month's highest 15-minute average, when it happened, and how close it is to your peak limit. Amber from 80 %. |
@@ -3244,8 +3245,8 @@ ERROR or WARNING line in the add-on log.
   **Check for inverters working against each other** is SAFETY-31, **Delivery
   check** SAFETY-42.
 - **Month peak** and **15-minute periods measured** are TARIFF-01 and
-  TARIFF-13. The store's state at start is the INFO line `capacity-tariff peak
-  store: …`, and the peak guard's full reason is on its log line.
+  TARIFF-13. The store's state at start is the INFO line `Month peak store:
+  …`, and the peak guard's full reason is on its log line.
 - ***name*: battery power reading stopped changing** is SAFETY-37/56/57. The
   ERROR line carries the full `STALE_READING` reason and when it clears.
 - The table at the top: **Why** is `messages.why()`, the arbiter's answer in