get_irs_cpi averages August–July but documents (and IRS practice uses) the 12 months ending August

`get_irs_cpi` in `policyengine_us/parameters/uprating_extensions.py` documents "the average C-CPI-U over the 12mo ending August" (and `c_cpi_u.yaml` carries the same convention comment), but computes:

```python
end = instant(f"{year}-08-01")
start = end.offset(-MONTHS_IN_YEAR, MONTH) # -> August of year-1
# months iterated: Aug(year-1) .. Jul(year)
```

i.e. an **August–July** window, one month earlier than the documented (and IRS-practice) **September–August** window ending August 31.

Effect is small but real everywhere: with the post-#9100 monthly actuals, the TY2027 factor is 181.9796 under the current window vs 182.4243 under Sep–Aug (≈ +0.24%); unrounded IRS-uprated consumers (e.g. the KY standard deduction) differ by a few dollars, and rounded federal parameters can cross rounding boundaries in some years.

Fixing it shifts every projected tax year's factor, so it needs its own PR with the corresponding test/partner recalibration — deliberately not smuggled into the #9100 data refresh.

Found by cross-family (Sol) review of #9100.

Start in policyengine_us/parameters/uprating_extensions.py at get_irs_cpi and compare its date window with the convention documented in c_cpi_u.yaml. Update the calculation to use the September–August window, then run the corresponding tests and partner recalibration checks mentioned in the issue. Done means the factors and affected uprated parameters reflect the corrected window.

Written by the indexing model from the issue text.