Fix civil-date public types: Day.date, currentPeriod, activeDate → YYYY-MM-DD strings

[bart-krakowski]

Parent

#25

What to build

Change every civil-date value at the public boundary from `Temporal.PlainDate` to a `YYYY-MM-DD` ISO string. This is a targeted breaking change that must land before the module API is built, so the correct types are foundational from the start.

Civil values affected: `Day.date`, `CalendarStore.currentPeriod`, `CalendarStore.activeDate`, and any all-day event boundary that is currently typed as `Temporal.PlainDate`.

Why: encoding a civil date as a `Temporal.PlainDate` leaks the Temporal polyfill into consumer types. Encoding it as a `Date` object introduces the all-day off-by-one bug (UTC-midnight reads incorrectly in west-of-UTC timezones). A `YYYY-MM-DD` string is the honest, zero-ambiguity representation of a calendar-civil day.

Instant-bearing values (event `start`/`end`) are unaffected — those remain `Date` objects.

Acceptance criteria

• `Day.date` is typed as `string` and carries a `YYYY-MM-DD` value
• `CalendarStore.currentPeriod` and `activeDate` are typed as `string` (`YYYY-MM-DD`)
• No `Temporal.PlainDate` appears in any exported type
• `Day.isoDate` (already present) is confirmed as the canonical fast-path key; `Day.date` and `Day.isoDate` carry identical values — one of them may be removed if redundant
• All existing tests updated to reflect the new types
• A consumer who previously accessed `Day.date.year` / `.month` / `.day` receives a TypeScript error pointing them to the ISO string instead

Blocked by

#26