fix: peticiones.py usa pedimento_app + post_or_update_document (T2025-09-004)

El stack viejo de descarga (utils/peticiones.py, via api_v1 + signal en backend)
armaba el nombre con campos crudos en vez de pedimento_app (vu_EDC, app 042_240_...)
y posteaba con post_document (sin reemplazar) -> documentos sin ligar la FK y
partidas duplicadas.

Las 8 funciones get_soap_* (pedimento_completo, remesas, partidas, acuse,
acuseCOVE, estado, edocument, cove) ahora arman el nombre con pedimento_app
(identico a api_v2) y postean con post_or_update_document + identifier.
Corrige tambien el prefijo vu_EDC -> vu_ED.

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

CHANGELOG.md

@@ -0,0 +1,37 @@
+# Changelog — EFC Microservice
+
+Historial de cambios por ticket (más reciente arriba). Reglas del flujo en `../CLAUDE.md`.
+
+## T2025-09-004 — Nomenclatura/dedup de descargas (stack legacy `peticiones.py`)
+- **Fecha:** 2026-06-24
+- **Tipo:** fix
+- **Repos:** microservice (lo dispara un signal en backend; ver `backend/CHANGELOG.md`)
+- **Branch:** `feature/T2025-09-004` · **PR:** (pendiente de aceptación manual)
+- **Rastreo (root cause):**
+  - Dos stacks de descarga corrían en paralelo. El NUEVO `api/api_v2/modules/*` usa
+    `pedimento_app` + `post_or_update_document` (liga la FK y reemplaza, no duplica). El
+    VIEJO `utils/peticiones.py` armaba el nombre con campos crudos
+    `{remesas}{no_partidas}{tipo_operacion}_{aduana}_{patente}_{pedimento}` (≠ `pedimento_app`),
+    usaba prefijo `vu_EDC` (no `vu_ED`) y posteaba con `post_document` (sin reemplazar → duplicaba).
+  - Disparador: el backend, al crear Pedimento/Cove/EDocument (p.ej. al cargar un datastage),
+    ejecuta el signal `api/customs/signals/procesamiento.py` (post_save) → tareas de
+    `api.customs.tasks.microservice` → `api_v1` → `peticiones.py`. En paralelo, el Celery beat
+    `microservice_v2.process_all_organizations` corre el stack v2.
+  - Síntoma observado (pedimento `5d9c6fb1...`, hoy): cada partida con 2 docs (uno por stack);
+    los edoc/acuse del stack viejo con app anómalo (`042_240_3452_6000382`) y `vu_EDC` → no
+    ligaban la FK; partidas "descargadas dos veces".
+- **Fix:** `utils/peticiones.py` — las 8 funciones de descarga
+  (`get_soap_pedimento_completo`, `get_soap_remesas`, `get_soap_partidas`, `get_soap_acuse`,
+  `get_soap_acuseCOVE`, `get_estado_pedimento`, `get_soap_edocument`, `get_soap_cove`) arman el
+  nombre con `pedimento_app` (idéntico a api_v2) y postean con `post_or_update_document` (con
+  `identifier` para partida/cove/edoc/acuses) → nombres correctos, FK ligada en `Document.save()`,
+  sin duplicar. Corrige también el prefijo `vu_EDC` → `vu_ED`. Como `peticiones.py` usa el
+  `APIController` (que no tenía ese método), se agregó `post_or_update_document` a `APIController`
+  en `controllers/RESTController.py`.
+- **Diseño / no-duplicidad:** el alcance del beat v2 (`ejecutar_basicos_organizacion`: solo
+  coves/edocs/acuses) es **intencional**; partidas/remesas/PC se procesan por el signal. La
+  no-duplicidad NO depende de unificar los stacks: con ambos flujos usando el MISMO nombre
+  (`pedimento_app`) + `post_or_update_document` con el mismo `identifier`, el segundo flujo en
+  correr **reemplaza** el documento del primero → no quedan filas duplicadas. (Residual: doble
+  descarga de coves/edocs por los dos flujos —perf, no duplicidad—; y una carrera de
+  concurrencia exacta se auto-corrige en la siguiente corrida del beat.)