Carry OBR Table 4.1's council tax decomposition rows (GB receipts total, accruals adjustment, surcharge)

[MaxGhenis]

Summary

Stacked on #189. Carries the rest of OBR EFO March 2026 Table 4.1's council tax block in obr-efo-expenditure-march-2026 (+17 facts, FY2024–FY2030):

row	concept	FY2025-26
15 'Total council tax receipts'	obr.council_tax_receipts_england_scotland_wales	£49,569,234,862
17 'Council tax accruals adjustment'	obr.council_tax_accruals_adjustment	£861,928,964
18 'High-value Council tax surcharge' (2028-29 onwards; earlier cells are blank and emit no facts)	obr.council_tax_high_value_surcharge	— (£454,292,600 in FY2028-29)

Why

The active UK calibration reference obr.council_tax binds the household variable council_tax_less_benefit to row 19 'Total net council tax receipts' (£50.925bn FY2025-26), which is the three nation rows (£49.569bn) plus NI domestic rates (£0.494bn, bound separately as obr.domestic_rates) plus an accruals adjustment (£0.862bn) with no household counterpart. Activating the held nation decomposition next to that binding would make the constraints jointly infeasible by ~£1.36bn. These rows make the redesign expressible as facts: a consumer can bind the GB cash-receipts total (row 15) or reconstruct row 19 exactly (rows 15 + 16 + 17 + 18, an identity pinned in the new test). Chosen with a cross-family review (fable + sol) recorded on #189; the microcosm-side redesign is a separate decision.

Same conventions as the rest of the package: explicit per-year record sets, exact row/column header guards, value_scale 1e9, FY2024 observation and later years source_projection, geography K02000001 matching the sibling rows. The percentage-change rows remain unported.

Tests

• tests/test_chronicle_obr_council_tax_decomposition.py (new): the row-15 = nations identity and the row-19 = 15+16+17+18 identity for every year, values, assertions, the surcharge's blank-cell years, and the package's 150-fact count.
• Merged-bundle goldens regenerated (+17 facts; obr 253 → 270).
• validate-package and build-suite pass; agent acceptance valid.

Chronicle governance

• Approved Chronicle agent role: ledger-source-ingestor.
• Deterministic checks run: source-package validation, build-suite (source-cell preservation, consumer-contract validation, raw-facts boundary validation), full pytest, ruff.
• LLM judge verdicts: ledger-source-fidelity — the three rows re-read from the pinned workbook cells and pinned by identity tests; ledger-boundary — PASS (publisher rows only; the binding redesign stays in microcosm); ledger-target-profile / ledger-contract — n/a.

🤖 Generated with Claude Code