fix(dates): make DAY precision locale-aware in formatDocumentDate

DAY precision routed through formatDate() which hard-coded de-DE, so an
en/es reader saw the German month name ("24. Dezember 1943"). Route DAY
through Intl.DateTimeFormat(locale, …) like the other branches, keeping
the T12:00:00 UTC-safety convention. Add en/es DAY+MONTH parity cases to
docs/date-label-fixtures.json (TS-only; the Java title formatter stays
German by design) and assert them in the spec.

Refs #666

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

docs/date-label-fixtures.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "Single source of truth for the honest date-label rule set shared by the TS formatDocumentDate (frontend/src/lib/shared/utils/documentDate.ts) and the Java formatTitleDate (backend importing/DocumentTitleFormatter.java). Both test suites assert against THIS table so the two implementations cannot drift (en-dash vs hyphen, 'ca.' vs 'circa', season words, range collapse). Expected labels are the GERMAN (de) canonical form: import titles are always German, and the TS formatter defaults to the de locale. Do not edit one side's expectation without editing this file and both tests. See issue #666 and the Markus/Sara drift-guard decision.",
+  "_comment": "Single source of truth for the honest date-label rule set shared by the TS formatDocumentDate (frontend/src/lib/shared/utils/documentDate.ts) and the Java formatTitleDate (backend importing/DocumentTitleFormatter.java). The 'cases' array holds the GERMAN (de) canonical form and is asserted by BOTH suites — that is the Java<->TS drift guard (en-dash vs hyphen, 'ca.' vs 'circa', season words, range collapse). The Java title formatter intentionally renders German server-side (import titles are always German); only the TS UI formatter is locale-aware, so 'localeCases' (en/es month-name output) is asserted by the TS spec ONLY and must NOT be fed to the Java test. Do not edit one side's expectation without editing this file and the relevant test(s). Season->month mapping note: the Python import normalizer (tools/import-normalizer) is the UPSTREAM authority for which representative month a season maps to (4/7/10/1); both formatters mirror it but it sits OUTSIDE this Java<->TS guard, so a normalizer change is not caught here. See issue #666 and the Markus/Sara drift-guard decision.",
   "cases": [
     {
       "name": "DAY renders a full long date",
@@ -97,5 +97,44 @@
       "raw": "?",
       "expected": "Datum unbekannt"
     }
+  ],
+  "localeComment": "TS-only locale parity for the read path (the younger phone audience may use en/es). Asserted ONLY by documentDate.spec.ts — the Java title formatter is German-only by design, so these MUST NOT be fed to DocumentTitleFormatterTest. Each case pins the localized month-name output for DAY and MONTH so a locale regression (e.g. a future de-DE hard-coding) is caught by the drift table, not just by ad-hoc tests.",
+  "localeCases": [
+    {
+      "name": "DAY in English renders the English month name",
+      "precision": "DAY",
+      "anchor": "1943-12-24",
+      "end": null,
+      "raw": null,
+      "locale": "en",
+      "expected": "December 24, 1943"
+    },
+    {
+      "name": "DAY in Spanish renders the Spanish month name",
+      "precision": "DAY",
+      "anchor": "1943-12-24",
+      "end": null,
+      "raw": null,
+      "locale": "es",
+      "expected": "24 de diciembre de 1943"
+    },
+    {
+      "name": "MONTH in English renders the English month name, never a day",
+      "precision": "MONTH",
+      "anchor": "1916-06-01",
+      "end": null,
+      "raw": "Juni 1916",
+      "locale": "en",
+      "expected": "June 1916"
+    },
+    {
+      "name": "MONTH in Spanish renders the Spanish month name, never a day",
+      "precision": "MONTH",
+      "anchor": "1916-06-01",
+      "end": null,
+      "raw": "Juni 1916",
+      "locale": "es",
+      "expected": "junio de 1916"
+    }
   ]
 }