Add council_tax_benefit to net income tree (matches HBAI methodology)

[MaxGhenis]

Summary

council_tax_benefit (CTR) was completely absent from PolicyEngine UK's net income tree: not in household_benefits.adds, not in hbai_household_net_income.adds, not in pre_budget_change_household_benefits.adds, and not in gov_spending.adds. The council_tax_benefit variable existed (adds = ["council_tax_benefit_reported"]) but nothing consumed it.

Meanwhile council_tax (gross billing, before CTR) is in household_tax.adds, so the model deducted the gross billed amount from household_net_income and never added CTR back. This diverges from DWP HBAI methodology, which counts CTR as benefit income and treats council tax as a deduction at the gross amount — net effect: income measured at gross-CT-minus-CTR (i.e. net CT).

Bug consequences before the fix

Baseline (no reform):

• CTR-recipient households' HBAI net income is understated by their CTR amount.
• All four poverty rates are overstated (more CTR-recipients tipped below the threshold than DWP would measure).

Under any reform touching council tax (e.g. gov.contrib.abolish_council_tax):

• Household net income rises by gross council tax, not net.
• gov_balance falls by gross council tax revenue, not net.
• The CTR-shaped gap (~£4bn aggregate at 2026-27 UK levels) appears as an unintended cash transfer in any abolition-style reform.

Fix

• Add council_tax_benefit to household_benefits.adds, hbai_household_net_income.adds, pre_budget_change_household_benefits.adds, and gov_spending.adds.
• The existing if abolish_council_tax: [b for b in benefits if b != "council_tax_benefit"] filters in household_benefits.formula and pre_budget_change_household_benefits.formula become meaningful (no-ops before).
• Apply the same filter pattern to hbai_household_net_income.formula (uses its own adds list) and a fresh gov_spending.formula (previously had no formula — just an adds list).

After the fix:

• Baseline HBAI net income for CTR-recipient households reflects net out-of-pocket council tax, matching DWP.
• Any reform abolishing council tax: household net income rises by net council tax; government balance falls by net council tax revenue.

Effect on baseline UK poverty rates (2026-27)

Direct policyengine_uk.Microsimulation on the Enhanced FRS 2023-24 dataset, calibrated to 2026-27:

Measure	Pre-fix	Post-fix	Δ
Absolute BHC poverty	11.35%	11.01%	−0.34 pp
Absolute AHC poverty	14.51%	14.25%	−0.26 pp
Relative BHC poverty	14.83%	14.68%	−0.15 pp
Relative AHC poverty	19.55%	18.55%	−1.00 pp

Relative AHC moves most because AHC subtracts housing costs (the threshold is a fixed share of median AHC income, which itself shifts when CTR is added to the income tree). All four baselines fall under the fix because the CTR-recipient households previously misclassified as below the poverty line now have their CTR counted as income.

Anyone running historical poverty comparisons should expect baseline numbers to shift under this PR. Reform-state values for abolish_council_tax reforms are unchanged (CT and CTR both vanish from the income equation regardless of which side they sit on) — only the baseline shifts, which means the change under reform shifts too, by the size of the baseline correction.

Test plan

• test_abolish_council_tax_removes_budget_impact (zero-CTR case, unchanged behaviour) — passes.
• New test_abolish_council_tax_nets_out_council_tax_benefit (CTR-recipient case: gross CT £2,000, CTR £800, expected refund £1,200) — passes; would have failed pre-fix.
• Full pytest suite locally with HUGGING_FACE_TOKEN — 140 passed, 1 skipped, no regressions.

Motivating analysis

Council-tax-to-LVT replacement scoring in PolicyEngine/uk-land-value-tax#8.

[vahid-ahmadi]

Approving. Traced the math and the fix is structurally correct: CTR was orphaned (variable existed, no aggregate consumed it), so baseline hbai_household_net_income deducted gross CT and added zero CTR back, and gov_balance showed gross CT revenue with no offsetting CTR spending. Adding CTR to the four aggregates and applying the abolish_council_tax filter consistently gives the right deltas on both sides.

Spot checks:

• Reform delta with CTR=£800, gross CT=£2,000: hbai_net_income +£1,200, gov_balance −£1,200. Matches the new test.
• Zero-CTR case (existing test, yaml parametric tests in hbai_council_tax_lvt.yaml): unchanged, since CTR was effectively absent from baseline anyway.
• BenUnit→Household aggregation via add(...) is consistent with how child_benefit (also BenUnit-scoped) is handled in these same lists, so no member-projection double-count.
• household_benefits.formula uprating: CTR will now be uprated by uprating.non_sp, which is consistent with how other non-SP benefits are treated.

Worth flagging (non-blocking):

1. Baseline poverty rates shift materially (PR description shows −1.00 pp on relative AHC). Cached baselines, dashboards, and any published comparisons downstream of policyengine_uk will need refreshing. A minor version bump rather than patch seems warranted given the user-facing effect.
2. gov_spending gains a formula for the first time. Functionally equivalent to the adds-only path when abolish_council_tax is false, but worth being aware of for any future reform that touches gov_spending.
3. Calibration sanity check (for whoever owns calibration, not blocking this PR): the change adds roughly £4 bn of CTR to baseline household_benefits and gov_spending. If calibration targets a national benefit-spending total, double-check CTR isn't already being absorbed via housing_benefit or the UC housing element.

Pre-existing nit (not introduced here): pre_budget_change_household_benefits.adds is missing several items present in household_benefits.adds (e.g., iidb, maternity_allowance). Out of scope for this PR.