feat: FK polimorfica Document -> {partida, cove, edocument} + backfill (T2025-09-004)

Reemplaza el matching fragil por nombre de archivo con FK reales:
- 3 FK nullables (CASCADE) en Document; resolucion central en save() por
  document_type + nombre (core.document_links), cubre toda ruta de creacion
  incluida la ingesta del microservicio; set explicito en create_vu_record.
- Comando backfill_document_links (idempotente, dry-run) para filas existentes.
- Lectura/descarga/borrado SIEMPRE por la FK (id); el nombre solo ESTABLECE la
  FK en save()/backfill. Prefetch con select_related(pedimento, fuente) sin N+1.
- Migraciones: 0004 (campos), 0005 (indices CONCURRENTLY IF NOT EXISTS, idempotente
  via SeparateDatabaseAndState), 0006 (ANALYZE document para estadisticas del planner).

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

api/record/migrations/0006_analyze_document.py

@@ -0,0 +1,22 @@
+# Recalcula estadísticas del planner tras crear los índices de las FK (0005).
+# CREATE INDEX CONCURRENTLY NO corre ANALYZE: sin estadísticas frescas de las
+# columnas nuevas (partida_id/cove_id/edocument_id, casi todas NULL antes del
+# backfill), el planner puede elegir un seq scan sobre la tabla `document` (~5M
+# filas) para las consultas del prefetch en vez de usar el índice → endpoints
+# muy lentos. Este ANALYZE lo previene en cada entorno.
+
+from django.db import migrations
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('record', '0005_document_subentidad_idx'),
+    ]
+
+    operations = [
+        migrations.RunSQL(
+            sql='ANALYZE "document";',
+            reverse_sql=migrations.RunSQL.noop,
+        ),
+    ]