Defensa en createWeeklyTracker: normalizar Date in situ

El error TypeError: estimatedEndDate.toLocaleDateString seguía
ocurriendo a pesar de rehydrateDates al cargar caché. Sin entender
todavía por qué la rehidratación no convierte el valor (posible que
el campo en storage no sea ISO-string sino algo no contemplado),
añado defense in depth: createWeeklyTracker normaliza los tres campos
Date (sessionStart, sessionEnd, estimatedEndDate) en su primera línea.

Es no-op cuando rehydrateDates funciona (instanceof Date → as-is) y
rescata el render cuando falla por cualquier motivo. Una llamada a
toLocaleDateString sobre un string ya no rompe la extensión.

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

content.js

@@ -492,6 +492,22 @@
   }
 
   function createWeeklyTracker(pageData, dailyData) {
+    // Defense in depth: si pageData/dailyData vienen del caché de chrome.storage,
+    // los Date pueden seguir siendo string/number aunque rehydrateDates haya pasado.
+    // Normalizar aquí mismo evita TypeError al llamar .toLocaleDateString/Time.
+    const ensureDate = (v) => {
+      if (v == null) return null;
+      if (v instanceof Date) return isNaN(v.getTime()) ? null : v;
+      if (typeof v === 'string' || typeof v === 'number') {
+        const d = new Date(v);
+        return isNaN(d.getTime()) ? null : d;
+      }
+      return null;
+    };
+    pageData.sessionStartTime = ensureDate(pageData.sessionStartTime);
+    pageData.sessionEndTime = ensureDate(pageData.sessionEndTime);
+    dailyData.estimatedEndDate = ensureDate(dailyData.estimatedEndDate);
+
     const container = document.createElement('div');
     container.className = 'claude-usage-tracker-container';
     container.id = 'claude-usage-tracker';