Fix Maine PTFC senior benefit base (mis-typed marginal scale) (#8813)

[DTrim99]

Fixes #8813.

Problem

The Maine Property Tax Fairness Credit under-computed the credit for filers whose older of head/spouse is exactly age 65+ (tax years 2024+): the enhanced senior benefit base silently never applied.

Root cause

parameters/.../fairness/property_tax/benefit_base/senior.yaml was missing metadata.type: single_amount, so its brackets loaded as a MarginalAmountTaxScale instead of a SingleAmountTaxScale. The marginal scale treats the bracket threshold as exclusive, so senior.calc(65) returned 0 at the exact threshold. The guard in me_property_tax_fairness_credit_base_cap (senior_benefit_base != 0) then fell back to the non-senior single base.

(This is why the existing age-66 test passed — above the threshold the marginal scale coincidentally returns the right amount; only age exactly 65 was broken.)

Fix

• Add type: single_amount (plus threshold_unit: year / amount_unit: currency-USD, matching the sibling cap.yaml) to senior.yaml.
• Add an age-exactly-65 regression test to me_property_tax_fairness_credit_base_cap.yaml: 2025 single filer, income $60,000, countable rent property tax $5,000 → base cap $1,700 (senior base $4,100 − 4% × income). Before the fix this returned $150 (fallback to the $2,550 single base).

References

• 2025 Form 1040ME Schedule PTFC/STFC (lines 7-9, 12)
• 36 MRS §5219-KK

🤖 Generated with Claude Code

[PavelMakarchuk]

Review: Fix Maine PTFC senior benefit base (mis-typed marginal scale)

Good catch and a correct, minimal fix. Requesting changes mainly to fix a pre-existing uprating bug that lives in the exact metadata block this PR edits — cheap to fix now — plus a wrong reference link and two test additions.

Verified correct (the fix)

• Adding type: single_amount makes senior.calc(65) return $4,100 (inclusive threshold), $0 below 65, unchanged at 66+, and $0 pre-2024 — verified empirically against SingleAmountTaxScale.calc. The bug was isolated to exactly age 65 (the marginal scale returned $0 there, tripping the senior_benefit_base != 0 fallback to the non-senior base). Metadata now matches sibling property_tax/cap.yaml; the incorrect pre-fix unit: currency-USD is correctly removed.
• Values confirmed against Maine sources: senior base $4,100 (2025 Schedule PTFC/STFC line 8) / $4,000 (2024, §5219-KK(1)(A-1)(4)), non-senior single $2,550, 4% rate, age 65+ (one spouse suffices), effective TY2024+. Regression test (age 65, 2025, $60k, $5k → $1,700 vs pre-fix $150) discriminates the senior path correctly; 9/9 tests pass.

Requested changes

1. Fix the senior base's uprating while you're in this block (pre-existing, but in-scope now). senior.yaml:14-18 declares uprating at the bracket level (uprating: gov.irs.uprating with a sibling rounding: key) instead of the working nested form used in single.yaml (uprating: {parameter: gov.irs.uprating, rounding: {...}}). Effect: the senior base stays flat at $4,100 for 2026+ instead of inflation-adjusting per 36 M.R.S. §5403, whereas single.yaml correctly steps 2,550 → 2,600 → … It's latent on main (not a regression) and doesn't affect the explicit 2024/2025 values — but since this PR is already rewriting senior.yaml's scale metadata, converting the uprating to the working nested form here avoids leaving the senior base understated in later years.
2. Reference fix: the "2024 Form 1040ME" entry (senior.yaml) links to 23_1040me_sched_pstfc_ff.pdf — the same URL as the 2023 entry. Point it at the actual 2024 form PDF (locate the real filename on maine.gov/revenue; a naive 24_… guess 404s).
3. Tests:
   • The age-64 case doesn't isolate the base (its output is driven by the under-65 cap, so it'd pass even if the senior base wrongly applied at 64). Add a discriminating age-64 mirror of the age-65 case (2025, $60k, $5k → $150).
   • Add an MFJ / one-spouse-65+ case (e.g. head 60 / spouse 67, 2025) to exercise the greater_age_head_spouse selection.

Suggestions

• Replace the senior_benefit_base != 0 sentinel in me_property_tax_fairness_credit_base_cap.py:19 with an explicit age / in-effect check for clarity (functionally correct today).
• senior.yaml description verb "allows for" isn't in the approved verb list (limits/provides/sets/excludes/deducts/uses) — pre-existing.
• Add absolute_error_margin to the older cases (1-4) for consistency with the newer ones.

🤖 Reviewed with Claude Code

[DTrim99]

Fixes applied (addressing @PavelMakarchuk's review)

Pushed as 2b424edf04.

Requested changes

• Senior-base uprating — converted the bracket-level uprating from the flat form (uprating: gov.irs.uprating + sibling rounding:, which silently left the base flat at $4,100) to the working nested form (uprating: {parameter: gov.irs.uprating, rounding: {…}}), matching single.yaml. Kept inside the bracket metadata so only the amount uprates (not the age threshold). The senior base now inflation-adjusts for 2026+ per 36 M.R.S. §5403.
• 2024 reference — the "2024 Form 1040ME" entry pointed at the 2023 PDF; repointed it to the actual 2024 Schedule PTFC/STFC (24_Form 1040ME_Sch PTFC_ff.pdf#page=2, verified live — shows "$2,000 ($4,000 if 65 or older)").
• Tests — added a discriminating age-64 case (2025, $60k, $5k → $150; senior base does not apply, so it can't pass if the base wrongly applied at 64) and an MFJ one-spouse-67 case (head 60 / spouse 67 → $1,700, exercising greater_age_head_spouse).

Suggestions

• Added absolute_error_margin to the older cases (1–4) and fixed the description verb ("allows for" → "provides").
• Left the senior_benefit_base != 0 sentinel in …_base_cap.py as-is (functionally correct today, per your note).

CI running now.