Panel history tabs, calculation dry run and opt-in calculation log

[frankyhun]

This PR brings the work done in the frankyhun/HAsmartirrigation fork (releases v2026.7.1 → v2026.7.4) back to dev. It is a mix of panel features, a calculation "preview" mode, an opt-in audit log for calculations, and two small fixes, plus tests and documentation.

Panel

Irrigation history tab (view-history.ts, new)
A new tab that lists what was actually watered. Runs are recorded when a valve run finishes (valve_runner.py) and when observed watering is registered (observed_watering.py), and persisted in the store. A new websocket command smart_irrigation/irrigation_history returns the raw records (start time in UTC, duration in seconds, water in litres) so the panel can group them by local calendar day and convert to the user's unit system — bucketing on the backend would use the server's idea of "a day".

Weather service retrieval history (view-weatherservice.ts)
The Weather service tab now shows the last retrievals, newest first, via a new smart_irrigation/weatherservice_history websocket command. Only sensor groups that actually take at least one value from the weather service are considered, and within a record only the weather-service-sourced values are returned — showing a sensor or static value on that tab would be misleading.

Durations as hh:mm:ss with water volume (view-info.ts, view-zones.ts, helpers.ts)
Run times were shown as a raw number of seconds. They are now formatted as hh:mm:ss on the Info tab and the Zones tab, and the corresponding water volume is shown next to them.

Panel module URL is versioned (panel.py)
After an update, browsers kept serving the cached smart-irrigation.js, so a new bundle only appeared after a hard refresh. The panel module URL now carries the integration version as a query parameter.

Hungarian label fix
hu.json: corrected the label for the sensor update interval.

Dry run for the calculate services

calculate_zone and calculate_all_zones accept a new dry_run: true option. A dry run computes the result and returns it without touching any irrigation data: the bucket, the zone, the collected weather data and the internal "last calculated" marker are all left exactly as they were.

The motivation: a normal manual calculation consumes the weather data collected so far and moves the "last calculated" marker, so the scheduled run later that day only sees a partial window. ET is computed as a full-day rate from that window and then scaled by its length, and because min/max temperature come from the samples inside the window, a partial window never contains the full daily temperature swing — the scheduled run then produces a lower daily total. A dry run avoids this.

One thing a dry run does still do: with PyETO and forecast_days > 0 it fetches forecast data, because the preview has to be computed from the same inputs to be meaningful. This is documented, together with the API-quota implication.

Since nothing is stored, the outcome is only available as the service response — result.zones carries delta, bucket, duration, current_drainage and et_deficiency per zone; all five keys are always present and are null when the module does not produce that value.

This also fixed a pre-existing bug found on the way: scheduler.py called the calculation helpers with the wrong arguments (test_scheduler_calculate_action.py covers it).

Opt-in calculation log

New calc_log.py. Two days with near-identical weather can produce very different watering volumes, and after the fact there is no way to see why — the diagnostics file shows the current state, not how it was reached.

When Calculation log is switched on in the general settings (off by default), each zone calculation appends one JSON object to config/smart_irrigation/calc_log.jsonl, in metric units, holding the whole chain:

• identification — local and UTC timestamp, zone, sensor group, calculation module, integration version;
• inputs — the interval used, and per field the aggregated value, the aggregation method applied, how many records went into it, their min/max, the source (sensor / weather service / static) and whether the value was carried over;
• module intermediates — for PyETO the latitude, elevation, coastal flag, day of year, et_rad, cs_rad, sol_rad (and whether it was measured or estimated from temperature), net_in_sol_rad, avp, net_out_lw_rad, net_rad and eto per day, plus the deltas and their mean; Passthrough and Static record their (fewer) inputs the same way;
• outputs — ET deficiency, interval multiplier, precipitation, delta, bucket before/after, max bucket, drainage rate and drainage, precipitation rate, resulting duration and volume.

Dry runs are logged too — they are exactly when one asks "why this number?" — but every record carries a dry_run flag so a dry run is never mistaken for a real calculation.

The file is capped at 2 MB and rotated (one backup kept), so it can be left on for a season. The most recent records are also included in the diagnostics download, with coordinates rounded and entity ids removed, so they can be attached to an issue in one step.

Tests and docs

New: tests/test_calc_log.py, tests/test_calculate_dry_run.py, tests/test_scheduler_calculate_action.py; test_diagnostics.py and test_panel.py extended.

Docs: a "Calculation log" section in configuration-general.md, a "Dry run" section in usage-services.md, and a "The calculated duration looks wrong" entry in usage-troubleshooting.md.

Translations updated for en, fr and hu.

Notes for the reviewer

• The series is rebased on current dev (10241e7) and merges cleanly. It contains only the 12 feature/fix commits — the fork's own release: v2026.7.2…v2026.7.4 commits and its CLAUDE.md / README changes are deliberately left out, so no version bump is included: manifest.json, const.py and frontend/src/const.ts stay at v2026.7.1 and the version is yours to bump when you release.
• frontend/dist/smart-irrigation.js was rebuilt from source on top of this branch (npm run build), so the committed bundle matches the sources at v2026.7.1 rather than carrying the fork's build.
• Verified locally against this branch: ruff check custom_components/smart_irrigation/ and black --check clean, and both pytest jobs from .github/workflows/pytest.yml green (217 passed in tests/, 40 in the test_helpers / test_performance / test_diagnostics selection).
• Upstream's recent fixes are preserved — the Riemann-sum-in-days fix (Riemann sum aggregation multiplies by dt in seconds instead of days, causing massive ET0/bucket blow-up #784) and the Passthrough precipitation fix (Wrong Calculation of Irrigation time using Passthrough #790) are untouched by the calculation changes here, and their tests still pass.