fix(addon): fail-low daily-volume fallback so orphaned zones can't free-run to 300 L

[JakeTheRabbit]

Why

Two rows were watering to 300 L/day while a third capped at ~100 L. Nobody chose 300 — it's a hardcoded engine fallback, and the split exposed a real bug.

Root cause — zone-count mismatch between the two layers:

• The integration only builds per-zone entities for range(1, num_zones + 1), and num_zones defaults to 1 (number.py:643). So it creates number.crop_steering_zone_1_max_daily_volume and nothing for zones 2/3.
• The engine ignores that count — _detect_zones (controller.py:467) probes for VWC sensors and runs P0→P3 for every physical zone it finds (3 here).
• Zones 2/3 therefore have no cap entity, so _zone_num(..., "max_daily_volume", 300) fell through to the hardcoded 300 L failsafe — above the integration's own 200 L UI maximum. Wired zone 1 honoured its real 100 L cap; orphaned zones 2/3 free-ran to 300.

What

Lower the engine's max_daily_volume fallback from 300 → 150 L so a missing/unavailable cap entity can never grant more daily water than the UI can even express (200 L max). This directly caps the orphaned rows.

Notes / follow-up

• This is a safety change to the fallback only — a correctly-wired zone reads its own entity and never touches it, so fresh/healthy installs are unaffected.
• The complete cure for the asymmetry is raising the integration's zone count so zones 2/3 get their own individually-settable cap entities. The fallback change makes the system safe regardless.
• Deploy = Rebuild, not Restart — a plain restart reuses the baked image and won't pick up this code change.

🤖 Generated with Claude Code

---

Generated by Claude Code