fix(backend): correct "next weekday" and harden resolvers against model output

Four defects found by review of the preceding commits.

"next <weekday>" was occurrence-anchored ("this" plus seven) rather than week-
anchored. Said on a Thursday, "Thursday next week" resolved to +14 instead of
+7: next week runs Sat 10-18 to Fri 10-24, so its Thursday is 10-23, not 10-30.
A lab case a week late. "next" now counts from the start of the following
Saturday-start week, which also lets "this" and "next" correctly coincide —
said on a Thursday, "the coming Saturday" and "Saturday next week" are the same
day. "this" stays occurrence-anchored so it can never resolve into the past.

The other three all come from the same root cause: exported functions that are
reachable from untrusted model output must degrade, not throw or drop.

- a non-object `due` (the model emitting a bare string) was treated as "no
  deadline spoken" and silently discarded; only null/undefined mean absent now,
  anything else is flagged so the clinician sees something was heard and lost
- isJalaliLeapYear / jalaliDaysInMonth threw for years outside the conversion
  table, contradicting the module's own "degrade to null" contract; they now
  return false / 0, which also makes isValidJalaliDate's day check naturally
  false
- civilDateInZone passed a client-supplied zone straight to Intl, which raises
  RangeError before any fallback; it now validates and backstops to UTC, so a
  bad zone costs at most a day rather than a 500

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

backend/src/common/jalali.spec.ts

@@ -72,6 +72,22 @@ describe('jalali calendar', () => {
     });
   });
 
+  describe('no export throws on an unsupported year', () => {
+    // The whole module is reachable from model-supplied values, so it degrades instead of
+    // raising — jalaliToIsoDate's guard is not the only entry point.
+    it.each([9999, -9999, 3178, Number.NaN, 1.5])('year %s', (jy) => {
+      expect(() => isJalaliLeapYear(jy)).not.toThrow();
+      expect(() => jalaliDaysInMonth(jy, 1)).not.toThrow();
+      expect(isJalaliLeapYear(jy)).toBe(false);
+      expect(jalaliDaysInMonth(jy, 1)).toBe(0);
+    });
+
+    it('returns 0 days for an impossible month', () => {
+      expect(jalaliDaysInMonth(1404, 0)).toBe(0);
+      expect(jalaliDaysInMonth(1404, 13)).toBe(0);
+    });
+  });
+
   describe('toLatinDigits', () => {
     it('normalises Persian digits and leaves everything else alone', () => {
       expect(

backend/src/common/jalali.ts

@@ -131,12 +131,28 @@ export function jalaliToGregorian(
   return [gy, gm, gd];
 }
 
+/** True when the year is inside the conversion table's supported range. */
+export function isSupportedJalaliYear(jy: number): boolean {
+  return Number.isInteger(jy) && jy >= MIN_JALALI_YEAR && jy < MAX_JALALI_YEAR;
+}
+
+/** False for unsupported years rather than throwing — see the module contract. */
 export function isJalaliLeapYear(jy: number): boolean {
+  if (!isSupportedJalaliYear(jy)) return false;
   const r = jalCal(jy, false);
   return r.leap === 0;
 }
 
+/**
+ * Days in a Jalali month, or 0 when the year or month is not real.
+ *
+ * Zero rather than a throw: every export here is reachable from model-supplied values, so
+ * the whole module degrades instead of raising. Zero also makes `isValidJalaliDate`'s
+ * `jd <= jalaliDaysInMonth(...)` naturally false.
+ */
 export function jalaliDaysInMonth(jy: number, jm: number): number {
+  if (!isSupportedJalaliYear(jy)) return 0;
+  if (!Number.isInteger(jm) || jm < 1 || jm > 12) return 0;
   if (jm <= 6) return 31;
   if (jm <= 11) return 30;
   return isJalaliLeapYear(jy) ? 30 : 29;

backend/src/common/zoned-civil-time.spec.ts

@@ -54,6 +54,14 @@ describe('zoned civil time', () => {
       expect(civilDateInZone(instant, 'Europe/Amsterdam')).toBe('2025-10-11');
     });
 
+    it('falls back to UTC on an invalid zone rather than throwing', () => {
+      // Intl raises RangeError on an unknown zone and this takes a client-supplied string.
+      const instant = new Date('2025-10-11T21:30:00.000Z');
+      expect(() => civilDateInZone(instant, 'Not/AZone')).not.toThrow();
+      expect(civilDateInZone(instant, 'Not/AZone')).toBe('2025-10-11');
+      expect(civilDateInZone(instant, '')).toBe('2025-10-11');
+    });
+
     it('zero-pads single-digit months and days', () => {
       expect(civilDateInZone(new Date('2025-01-05T12:00:00.000Z'), 'UTC')).toBe(
         '2025-01-05',

backend/src/common/zoned-civil-time.ts

@@ -61,8 +61,12 @@ export function civilDateJsWeekday(isoDate: string): number {
  * client-supplied date, which matters for relative deadlines like "by Thursday".
  */
 export function civilDateInZone(date: Date, timeZone: string): string {
+  // Intl throws RangeError on an unknown zone, before any fallback below could help, and
+  // this receives a client-supplied string. Callers validate first; this is the backstop
+  // so a bad zone degrades to a date that is at most a day out rather than a 500.
+  const zone = isValidIanaTimeZone(timeZone) ? timeZone : 'UTC';
   const parts = new Intl.DateTimeFormat('en-CA', {
-    timeZone,
+    timeZone: zone,
     year: 'numeric',
     month: '2-digit',
     day: '2-digit',