Simplify Calendar.day (now read-only)

[danielparks]

Calendar.day is only really used by tests. This radically simplifies
it by removing its ability to create Days, so it is now only used to
access a Day by date.

This also removes the unused Calendar.existingRepoDay and makes
Calendar.normalizeDays and Calendar.repoDayForDay private.

This removes a bunch of tests related to calendar modification and
normalizeDays, since we now expect calendar ranges to be pre-declared,
and normalizeDays will be simplified in a future change (it’s only
used for testing).

[claude]

The ! here would surface as a TypeError: Cannot set properties of undefined rather than an AssertionError if day() ever returned undefined. Consider using assertExists to get a clearer failure message:

Suggested change

	calendar.day(new Date(2024, 11, 30))!.contributionCount = 3;
	const dec30 = calendar.day(new Date(2024, 11, 30));
	assertExists(dec30);
	dec30.contributionCount = 3;

[claude]

Addressed — the update uses assertExists + a named variable, matching the suggestion exactly.

[claude]

Same ! concern as the previous test — a regression would throw TypeError instead of AssertionError.

Suggested change

	calendar.day(new Date(2025, 0, 3))!.contributionCount = 3;
	const jan3 = calendar.day(new Date(2025, 0, 3));
	assertExists(jan3);
	jan3.contributionCount = 3;

[claude]

Addressed — same assertExists pattern applied here too.

[claude]

This only covers the empty-calendar case. There's no test for day() returning undefined when the calendar is non-empty but the requested date is out of range. Something like:

Deno.test("Calendar.day() returns undefined when date is out of range", () => {
  const calendar = new Calendar("testuser", [new Day(new Date(2025, 0, 1), 5)]);
  assertEquals(calendar.day(new Date(2025, 1, 1)), undefined);
});

[claude]

Addressed — "Calendar.day() should return undefined when out of range" covers exactly this case.

[claude]

Clean simplification overall — removing the day-creation side effect from day() makes the API much easier to reason about, and making #normalizeDays/#repoDayForDay private is overdue. Grep confirms neither day() nor repoDay() has any production callers outside Calendar.ts itself, so the behavior change is safe.

A few minor notes (details inline):

• The two tests that use ! on calendar.day() would surface regressions as TypeError rather than AssertionError. assertExists would give clearer output.
• The test at line 234 covers only the empty-calendar case; there's no test for day() returning undefined when the calendar is non-empty but the date is out of range.
• The test names "should handle earlier/later day in the initial week" now describe behavior of #normalizeDays (which pads to full weeks) rather than day(), since day() no longer creates anything. Optional rename, but the names are slightly misleading.

[claude]

All three issues from my prior review are addressed: the two non-null assertion uses replaced with assertExists, and the out-of-range test added. LGTM.