fix(sprint-5/etapa-4e): lockAcquireTimeout 30s + eliminar getSessionSafe — corta freeze en guardar perfil

getSessionSafe() tenía un problema de diseño: Promise.race([getSession(), timeout])
abandona la Promise de getSession() cuando gana el timeout. La Promise abandonada
deja una operación en PROCESS_LOCKS[name] que bloquea el chain. Con lockAcquireTimeout=5s
(default), un token refresh lento dispara ProcessLockAcquireTimeoutError cuyo handler
hace await previousOperation (colgada) → freeze permanente.

Fix: lockAcquireTimeout: 30000 (margen para redes lentas) + eliminar getSessionSafe()
de supabase.ts, library-store, process-store y useReportData. Las queries Supabase
llaman getSession() internamente vía _getAccessToken() que espera initializePromise
automáticamente — la barrera era redundante.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

src/lib/supabase.ts

@@ -18,16 +18,10 @@ export const supabase = createClient(supabaseUrl, supabaseAnonKey, {
     // navigator.locks) — evita el deadlock a costa de no sincronizar refresh entre tabs,
     // lo cual es aceptable para este producto (uso mayormente single-tab).
     lock: processLock,
+    // Aumentado de 5000 (default) a 30000ms.
+    // Con 5s, un token refresh lento dispara ProcessLockAcquireTimeoutError, cuyo handler
+    // hace await previousOperation (colgada) → chain bloqueado permanente.
+    // 30s da margen para refresh en redes lentas o cold starts de Supabase Auth.
+    lockAcquireTimeout: 30000,
   },
 })
-
-// supabase.auth.getSession() puede colgarse indefinidamente si el cliente queda
-// esperando un lock interno (navigator.locks) que nunca se libera. Esta barrera
-// nunca bloquea más de 4s: si no resuelve a tiempo, sigue de largo sin sesión confirmada
-// en vez de dejar la UI con un spinner/skeleton infinito.
-export async function getSessionSafe(): Promise<void> {
-  await Promise.race([
-    supabase.auth.getSession(),
-    new Promise((resolve) => setTimeout(resolve, 4000)),
-  ])
-}