[CaffeinatedCoder]

Closes #450

Problem

Three sentences about the calendar factories in docs/efcore.md#what-runs-where were imprecise:

1. The LocalDateRange/YearMonthRange row, the EF Core README, the four calendar entries in translation-support.json and NodaCalendarFactoryClientSideTests' summary said "the years before 4713 BC have no PostgreSQL date", and led with -infinity. PostgreSQL's first date is 4714-11-24 BC. The month and the year that hold it can't be built (date_trunc raises "timestamp out of range"), with Npgsql's infinity conversions on or off.
2. "The first and last periods end at -infinity and infinity": the first period starts there. With Npgsql.DisableDateTimeInfinityConversions set, both are the days themselves.
3. "PostgreSQL raises an error that names the argument": a month, a quarter and the year 0 go to make_date, whose error shows the date it was asked to build (Quarter(2026, 5) → 2026-13-01). Only the year and week guards name the argument.

Change

• (1) The same reason, in all five places.
• (2) The extremes sentence is reworded, and E76's quote follows it.
• (3) The error sentence says which argument gives which message.

The decision to keep the NodaTime forms in memory is unchanged.

Tests

Docs only. Each statement was measured on PostgreSQL 16.15: '4714-11-24 BC'::date works and '4714-11-23 BC'::date doesn't; date_trunc('month'|'year', …) over PostgreSQL's first day raises; and make_date(2026, 13, 1) and make_date(0, 6, 1) print the date. OracleCatalogueTests holds E76's quote to the new sentence. The conventions tests (417) pass.

🤖 Generated with Claude Code