fix: a day that does not exist costs one field, not one house

[skishchampi]

A P1 that Codex filed on #142 and that merged unfixed. The review carried two comments. I read one, answered it, and pushed. The other one is this.

The defect. 2025-02-30T00:00:00Z passes the shape test and the range test, then strptime raises a bare ValueError. _record() catches UnreadableDate alone, so the error reaches the house-level handler in probe(), writes one fetch_error, and abandons every later bill in that house.

That is exactly the failure 0.15.0 fixed for other date shapes. One bad field must cost one field.

The fix. The rung raises UnreadableDate with the day named. The field goes to null, fetch_status becomes parse_error, and the bill keeps its name, ministry, status and file URLs.

Tests, both reproduced first:

• test_an_impossible_day_raises_unreadable_not_value_error
• test_the_house_survives_an_impossible_day — a bad bill first, a good bill second, and the good one must still arrive.

Neighbours checked, since this is the class where my own fixes have bitten before: 2025-02-29 00:00:00.0 and 31/02/2025 already raised correctly through the _DATE_FORMATS loop, and 2024-02-29T00:00:00Z still reads, because 2024 is a leap year.

1805 passed, 2 skipped, ruff clean.

This ships in 0.15.1.