Fix calendar window overshooting the cached year range

Found by probing the running API; both suites were green and missed it.

CalendarService validated only start_year against the cache, never the window
end. GET /api/calendar/days?start_year=2035&years=4 returned 200 with
end_year=2038, pulling 2036-2038 from the live holidays-library fallback in
app/utils/holidays.py. That fallback does not know the de facto free days, so
Julafton, Nyarsafton and Midsommarafton were reported as ordinary working days
(18 red days per cached year vs 13 per uncached year). Julafton being charged
as a working day was fixed once before; it had reappeared past 2035.

- clamp end_year to max_year; the response now always reports what it returned
- add strict=True to get_swedish_holidays/get_red_days plus UncachedYearError,
  checked before the memo cache, so a strict caller fails loudly rather than
  silently degrading. Non-strict default behaviour is unchanged.
- RedDaysList derived endYear locally as startYear + years - 1, independent of
  the response, so a clamped window rendered phantom empty years. It now takes
  endYear from the backend.

Tests: clamping at and before max_year (service + router), Julafton/Nyarsafton/
Midsommarafton red for every cached year, red-day count consistent across the
served range, and strict-mode raise/pass-through.

Backend 404 -> 414 tests, frontend 704 -> 705.

Known, deliberately not fixed here: AllocationInputLoader builds its holiday map
the same non-strict way over the planning horizon, so it has the same exposure
once the horizon passes 2035. Clamping would silently truncate planning and
raising would break real plans, so it needs a product decision first.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RXMhc9nT6sNz1SL4j8dznL

backend/tests/unit/test_calendar_router.py

@@ -99,6 +99,40 @@ class TestGetCalendarDays:
 
         assert response.status_code == 422
 
+    async def test_a_window_reaching_the_cache_end_is_clamped_not_overshot(
+        self, client: AsyncClient, connection: aiosqlite.Connection
+    ) -> None:
+        """Regression test for the real bug: `start_year=<max_year>&years=4`
+        used to return 200 with `end_year = max_year + 3`, silently serving
+        years past the cache from the degraded `holidays`-library fallback
+        (missing Julafton/Nyårsafton/Midsommarafton). It must now clamp to
+        the cache and report the ACTUAL served range.
+        """
+        workspace_repo = SQLiteWorkspaceRepository(connection)
+        ws = await workspace_repo.create(
+            Workspace(id=uuid4(), name="Familj", created_at=datetime.now())
+        )
+
+        # Discover max_year from a normal response rather than hardcoding it.
+        bounds_response = await client.get(
+            "/api/calendar/days",
+            params={"workspace_id": str(ws.id), "start_year": 2026},
+        )
+        max_year = bounds_response.json()["max_year"]
+        assert max_year is not None
+
+        response = await client.get(
+            "/api/calendar/days",
+            params={"workspace_id": str(ws.id), "start_year": max_year, "years": 4},
+        )
+
+        assert response.status_code == 200
+        body = response.json()
+        assert body["start_year"] == max_year
+        assert body["end_year"] == max_year, "end_year must report the clamped range, not overshoot"
+        years_seen = {int(d["date"][:4]) for d in body["days"]}
+        assert years_seen == {max_year}, "no day may come from beyond the cache"
+
     async def test_workspace_day_overrides_are_merged_into_the_response(
         self, client: AsyncClient, connection: aiosqlite.Connection
     ) -> None: