fix(kraken): scale exc-VAT applicableRates prices to inc-VAT from the agreement

[springfall2008]

Fixes #5417

Problem

When REST cannot serve a tariff's rates, the Kraken component falls back to GraphQL applicableRates and stored its single value as value_inc_vat. The BottlecapDave-derived EDF integration (stevekirtley/HomeAssistant-EDFEnergy) treats that value as exc-VAT and scales it up. On that basis Predbat's import rates are 5% low for tariffs that take the fallback every cycle: EDF day/night tariffs (#5166), E.ON TOU tariffs and products retired from the REST API.

Tariffs served by REST are unaffected, as is export.

Fix

• The account query now also asks for standingCharge and preVatStandingCharge on the tariff. Both are on the TariffType interface on EDF and E.ON (checked by live introspection).
• Their ratio is the VAT multiplier. It is accepted only between 1.0 and 1.25; anything missing, zero or outside that range leaves prices unscaled, which is the previous behaviour.
• Import applicableRates values are scaled by it. Export is passed 1.0.
• The multiplier is refreshed on every tariff discovery (the VAT rate can change while the tariff does not), kept off the tariff dict so it never reads as a tariff change, and cached across restarts.
• value_exc_vat is now the raw value, replacing the hardcoded / 1.05. Nothing outside kraken.py reads it.

No VAT rate or date is hardcoded: the multiplier is 1.0 during the GB zero-rate window (1 Oct 2026 – 31 Mar 2027) and 1.05 afterwards.

What reviewers should know

• No visible change today. Electricity is zero-rated now, so the multiplier is 1.0 and published rates are identical. The difference appears on 1 April 2027.
• The exc-VAT basis is not independently confirmed. It is the EDF integration author's assertion; the schema has no description for the field and nobody has compared a raw applicableRates value against a bill. If it turns out to be inc-VAT, this PR would overstate fallback-path import rates by 5% from April.
• Standing charge fallback untouched. GraphQL applicableStandingCharges is still assumed inc-VAT and is unverified either way.
• Across a VAT change the multiplier in force now is applied to every period in the fetch window, so rates for periods on the far side of the boundary are out until the boundary passes.

Testing

./run_all --test kraken --test kraken_auth passes. New tests cover the multiplier derivation and its guards, discovery storing and refreshing it, import-only scaling in the fallback, and the cache round trip including a cache written before the field existed. Pre-commit passes on the changed files. Not run against a live account.

A debug journal row records the investigation, including the dead ends.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🔵 Needs a closer look

The pricing basis remains independently unverified and the change has not been validated against a live affected account.

Review effort: Balanced
Findings: None

What changed in this PR

Updates Kraken’s GraphQL fallback to convert import prices from exclusive to inclusive VAT using agreement data.

Changes:

• Derives, caches, and applies an import VAT multiplier.
• Keeps export rates unscaled and adds regression tests.
• Documents the VAT-basis investigation.

File	Description
apps/​predbat/​kraken.py	Implements VAT multiplier handling.
apps/​predbat/​tests/​test_kraken.py	Tests derivation, scaling, and caching.
tools/​debug-journal.md	Records investigation findings.
.cspell/​custom-dictionary-workspace.txt	Adds the referenced author’s name.

---

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