fix(control): size per-phase relief by the site's phase count

[frahlg]

Replaces #808, which GitHub closed by itself when #803 merged and its base branch was deleted. A force-push after that close blocks a reopen, so the same commit lands here instead: rebased onto master with #803's now-merged commit dropped. The content did not change — git diff master...HEAD is byte-identical to the diff #808 carried.

One commit on master now. #809 stacks on this one.

The bug

perPhaseOverageW(...) * 3.0 was written twice in dispatch.go — once in applyFuseGuard, once in forceFuseDischarge — while SiteFusePhases sat in the same State struct and fuseSafetyMarginW, two functions away, read it correctly and says so in its own comment: "No hardcoded 230 V / 3 phases here — both come from config."

A worst-phase overage is watts on one phase. Dispatch commands aggregate battery watts. The conversion between the two is the site's phase count: a battery spreads its action across the phases, so each aggregate watt relieves 1/N on the worst phase and an overage of N watts needs N × phases of action. Writing that as 3.0 is only right on a three-phase site.

On a 1-phase site the aggregate meter and the single phase are the same wire, so the two numbers must agree — and they didn't:

1Φ site, 16 A fuse, 0.5 A margin, meter at 5520 W (24 A)	relief demanded	resulting meter
correct (× 1 phase)	1955 W	3565 W import — exactly the ceiling
before (× 3)	5865 W	345 W export — through zero, wrong side of the same breaker

perPhaseOverageW had two more of the same flavour. It walked L1/L2/L3 unconditionally, so current reported on a phase a 1Φ site does not own fired the clamp on a site nowhere near its fuse. And it fell back to a hardcoded 230 for voltage — the exact thing fuseSafetyMarginW refuses to do.

The fix

One helper, perPhaseReliefW, owns the conversion, and both call sites use it.

• Phase count comes from SiteFusePhases.
• Voltage comes from SiteFuseVoltage, the way every other watt in this file gets it (fuseSafetyMarginW, Fuse.MaxPowerW, main.go's fuseMaxW). No invented 230 V.
• Only the configured phases are read, in L1/L2/L3 order — the same rule sitePhaseCurrentsAt already follows in cmd/ftw/site_dispatch_safety.go.
• A fuse described by amps alone now gets no per-phase clamp instead of one computed from numbers nobody configured. config.go defaults fuse.voltage to 230 and fuse.phases to 3 and rejects <= 0 in validation, and control_state.go copies all three fields, so no configured site loses protection — only harnesses that wire SiteFuseAmps alone.

Was the import-only gate intentional or drift?

Intentional, and it stays. The two call sites genuinely need different behaviour:

• forceFuseDischarge has exactly one lever: command more discharge. That relieves an import-side phase and worsens an export-side one. Honouring a direction-agnostic overage there would push the over-current phase further over the breaker.
• applyFuseGuard has both levers — shrink charge, shrink discharge — so it uses relief in both directions and attributes it by the live aggregate sign.

The evidence: the gate arrived with the PR #219 review, its comment says so, and TestForceFuseDischargeIgnoresExportSidePerPhase has pinned it since. So the answer to "one of these two is wrong" is that the duplicated * 3.0 was the wrong half, not the gate. What was wrong about the gate is that it was the only thing distinguishing the sites while the conversion was silently duplicated. The direction limit now sits at the call that needs it; the conversion is stated once.

Tests

fuse_saver_test.go pinned 3-phase behaviour only. New siblings, all four of which fail against the old code:

• TestPerPhaseReliefMatchesSinglePhaseSiteOnImport — 1Φ site, idle battery: forced discharge equals the overage once, and the post-dispatch meter stays on the import side of zero.
• TestPerPhaseReliefMatchesSinglePhaseSiteOnExport — the export direction forceFuseDischarge deliberately skips and applyFuseGuard owns: same law, one phase count. Under × 3 the discharge is zeroed and the site swings to 520 W of import.
• TestPerPhaseClampReadsConfiguredPhasesOnly — a 1Φ site with L1 at 10 A ignores 24 A reported on phases it does not have.
• TestPerPhaseClampOffWhenFuseDescriptionIncomplete — amps without a voltage or a phase count clamp nothing.
• TestPerPhaseClampUsesConfiguredVoltage — a 240 V site converts at 240 V (2560 W, not the 2620 W a hardcoded 230 V gives).

setupPerPhase now states the site it builds (3Φ, 230 V) and delegates to setupPerPhaseSite, which takes both.

Golden corpus

Predicted before looking: zero records move. The corpus was recorded on 3-phase sites, so × SiteFusePhases is arithmetically × 3.0 there, the walk covers the same three phases, and the configured voltage is the same 230 V the fallback invented.

Verified after: TestGoldenCorpusReplay passes unchanged at the 0.01 W tolerance, all 590 records, and TestGoldenCorpusCoverage still reports per_phase=33 — the same records exercise the path, none of them silently switched off. Every record in the corpus that carries phase amps is site_fuse_voltage=230, site_fuse_phases=3; the 33 with a non-zero per-phase overage are all in that set.

make verify green (pre-commit gate).